Mir client API extensibility

Robert Ancell robert.ancell at canonical.com
Tue Sep 3 04:31:16 UTC 2013

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.


On Thu, Aug 15, 2013 at 3:19 PM, Christopher James Halse Rogers <
chris at cooperteam.net> 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<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130903/b8be46e2/attachment.html>

More information about the Mir-devel mailing list