Mir client API extensibility

[Daniel van Vugt]

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 bloat from duplicate template 
instantiations across SO's. I don't see any good reason to divide 
libmirclient up right now...

It's possible you're also thinking about the imperfection of the 
mir_debug_ calls added recently. Those two particular functions could be 
unified and cleaned up under one:
    int mir_surface_get(MirSurface *s, MirSurfaceAttrib a);
which functionally exists already just under the hood of libmirclient.

- Daniel


On 15/08/13 11:19, Christopher James Halse Rogers wrote:
> 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 and Unity8. We
> already have a bunch of client API that only makes sense for u-s-c
> clients or Unity8 clients¹ but that is available to both because both
> clients share the same API. I expect this to only get worse over time,
> as both u-s-c and Unity8 gain features. This is also an impediment to
> anyone else who wants to use Mir to write a compositor.
>
> I think that having entry points in the client API that clients cannot
> call is ugly, and we should work to avoid it.
>
> I think this lends itself to an extension solution; the core bits of API
> common to all clients - connection creation, surface creation, buffer
> management, etc - live in mirclient, and the bits specific to the
> environment live in mirclient-system and mirclient-session.
>
> Clients would then link against the libraries they need, and we'd have
> the ability to fail connections to compositors which do not support what
> the client requires.
>
> This leaves open the possibility of optional extensions; I've not got
> strong opinions on them.
>
> What do other people think about this? Do people share the feeling that
> this is a problem to solve?
>
> Chris
>
> ¹: 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.
>
> mir_surface_{get/set}_type make no sense for u-s-c clients, but are
> obviously required for Unity8 clients
>
>