Mir client API extensibility

[Christopher James Halse Rogers]

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