Mir client API extensibility

[Christopher James Halse Rogers]

On Thu, Aug 15, 2013 at 3:27 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> 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. We've not yet got too much stuff that's obviously and 
totally unnecessary in a given server, but I think we'll get some - 
copy/paste and drag and drop spring to mind.

>  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 
> 
‘2’

No, I'm not thinking about them at all, although that would be a nice 
cleanup.

I'm thinking that we're currently required to support two different 
use-cases with the same API, and I'm concerned that the intersection of 
the APIs required by both use cases is going to become a smaller and 
smaller part of the whole API.

We're going to need a drag-and-drop API and a copy-paste API; neither 
of those are sensible for the system compositor. We're going to need a 
surface *resize* API; even that makes no sense for the system 
compositor.

On the other side we've got the multihead configuration API, the write 
end of which Unity8 will want to deny to all clients.

> - 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
> >
> >
> 
> -- 
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>