I don't think the current Mir API is big enough to warrant splitting it up
- the overhead of doing this will cause packaging and API maintenance
headaches but probably not make the API any easier to use for developers in
my opinion. The number of developers directly interfacing to Mir is quite
smal
I also disagree with your examples...
> ¹: For example:
> mir_connection_apply_display_config only makes sense for u-s-c clients;
> Unity8 clients should not be able to fiddle with the display
> configuration in this way.
Wrong. We will need some kind of control-center client which can
configur
On Thu, Aug 15, 2013 at 3:27 PM, Daniel van Vugt
wrote:
I strongly recommend against dividing libmirclient into many
libmirclient*'s.
I wouldn't expect there to be many libmirclient*s; two would be my
guess.
And it's not just mirclient - the server currently has to implement
these things
I strongly recommend against dividing libmirclient into many
libmirclient*'s. It makes things much harder for people to understand
and will lead to increased time wastage for users. Not to mention
increased maintenance burden for us. And the third disadvantage is
significantly increased code bl
Or: Fragmenting Mir Clients The Right Way™
This is mainly a missive to get us to start thinking about how - and
whether - we want to handle extensibility in the Mir client API.
This is motivated by the observation that we currently have two
different targets for Mir: unity-system-compositor a
