Mir client API extensibility

[Daniel van Vugt]

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 
configure and change the display config. That is true for Unity8, any 
shell, games, etc.

 >
 > mir_surface_{get/set}_type make no sense for u-s-c clients, but are
 > obviously required for Unity8 clients
 >

Right, so only USC has no use for mir_surface_{get,set}_type. But why 
care? For real toolkits speaking native mir (post-XMir), such functions 
are critical. Just because there's one use case which doesn't require a 
function, does not mean removing the function.

And again, the Mir libraries already have significant template bloat. We 
would need to have a very good reason to increase disk and memory 
footprints further by splitting libraries.

- Daniel


On 15/08/13 15:55, Christopher James Halse Rogers wrote:
> 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
>>
>