Subject: Re: Mir client API extensibility

From: Daniel van Vugt <[email-masked]>
Date: Thu, 15 Aug 2013 13:27:22 +0800

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
>
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 15 Aug 2013 08:05:44 +0010

On Thu, Aug 15, 2013 at 3:27 PM, Daniel van Vugt 
<[email-masked]> wrote:
> 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 
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.

> -- 
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 15 Aug 2013 16:14:03 +0800

I also disagree with your examples...

 > 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.

 > 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:
> I wouldn't expect there to be many libmirclient*s; two would be my guess.
>
>>  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...
>>
> 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.
>

---

From: Robert Ancell <[email-masked]>
Date: Tue, 3 Sep 2013 16:31:16 +1200

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
small and they will probably read documentation rather than headers, so
this just becomes a documentation problem.

Over time I can see us needing to add more messaging to the protocol that
doesn't belong in the "core" Mir protocol. Things like communication
between XMir and Unity System Compositor that work best architecturally by
using the same links for simplicitly, reliability and security. Some of
these interfaces also might have a limited lifetime and putting them into a
core protocol would add bloat.

+1 some form of extensibility in the Mir client protocol.

--Robert

On Thu, Aug 15, 2013 at 3:19 PM, Christopher James Halse Rogers <
[email-masked]> wrote:

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