<div dir="ltr"><div><div><div>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.<br>
<br></div>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.<br>
<br></div>+1 some form of extensibility in the Mir client protocol.<br><br></div>--Robert<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 3:19 PM, Christopher James Halse Rogers <span dir="ltr"><<a href="mailto:chris@cooperteam.net" target="_blank">chris@cooperteam.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Or: Fragmenting Mir Clients The Right Way™<br>
<br>
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.<br>
<br>
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.<br>

<br>
I think that having entry points in the client API that clients cannot call is ugly, and we should work to avoid it.<br>
<br>
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.<br>

<br>
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.<br>
<br>
This leaves open the possibility of optional extensions; I've not got strong opinions on them.<br>
<br>
What do other people think about this? Do people share the feeling that this is a problem to solve?<br>
<br>
Chris<br>
<br>
¹: For example: <br>
mir_connection_apply_display_<u></u>config only makes sense for u-s-c clients; Unity8 clients should not be able to fiddle with the display configuration in this way.<br>
<br>
mir_surface_{get/set}_type make no sense for u-s-c clients, but are obviously required for Unity8 clients<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/mir-devel</a><br>
</font></span></blockquote></div><br></div>