Shell communication channel: simple, half-assed or fully-arsed?

Gerry Boland gerry.boland at
Thu Dec 12 16:33:34 UTC 2013

Hash: SHA1

On 11/12/13 14:00, Alan Griffiths wrote:
> I'm trying to summarise some discussions around the need for Mir
> to provide a ABI stable channel of communications to shells and
> client toolkits (such as unity8/platform-api) that make use of it.
> This should allow messages to be passed that Mir has no need nor
> ability to interpret.
> Future nice-to-haves: o consistency between shells and a framework
> for protocol extensions o some messages to be meaningful to Mir to
> enable optimizations o Migrating the current API (e.g. attribute
> setting) onto the same channel
> There are several approaches to this.
> *Simple/Simplistic
> *This is what I've sketched out in 
>  Mir simply punts all concerns about protocol negotiation,
> versioning and structure to the shell and relies on the shell to
> provide all information that Mir will ever need.
> The advantage of this approach is that we can do it without
> further discussion and unblock unity8 work.
> The disadvantage of this approach is that the "nice to haves" are
> left as an exercise for the interested Mir user.
> *Half-assed*
> Mir can provide some helpful fields - e.g. a protocol-id, 
> version-number**and message-discriminator to pass with the message
> - and define some base protocols (sizing, copy-paste,
> protocol-extension). Mir (or "shellinator") can then implement
> defaults for the base protocols.
> We discussed this last week and felt that it raised more issues
> than it addressed.
> *fully-arsed*
> Projects like X11 and Wayland have effective protocol definition
> and extension mechanisms. We should build on this - Wayland being
> the better example as it builds on the X11 experience.
> I don't yet have a clear vision of what a successful implementation
> of this approach looks like - and suspect that different team
> members have differing thoughts on how we would go about this.
> *Conclusion*
> I think that we should discuss the fully-arsed and flesh out some 
> specific ideas. But as that may not lead to a quick (or any)
> conclusion it is worth implementing the simple approach in parallel
> so as to unblock unity8 development.

Hey Alan,
I'm of the opinion that initially we will need to rapidly iterate on
the protocol between shell and client, which is something an opaque
channel lets us do with ease. Since right now I think that none of
those messages will interest Mir directly (shell will inform Mir if
any client message is relevant to it) so it can be a just simple
messaging channel.

I don't really see the advantage of your "half-assed" idea, as it
blurs the boundary between what Mir should define, and what it should
not. As we iterate, this boundary I imagine will move again and again!

However I do agree that longer term, having a client/shell messaging
channel without any defined protocol will introduce many problems once
other toolkits and shells start using Mir. We don't want each
shell/client pair having their own protocol, incompatible with our own.

So I would propose that at some point in future, at the point we have
shell performing to our requirements, that we review the client/shell
protocol that organically grew to satisfy those requirements, to see
how to clean it up and standardize it.

My thinking is that the client/shell protocol definition would live in
a project shared between unity-mir and platform-api (and probably
"shellinator"?). Then when it has stabilized, it can be moved directly
into Mir itself, or at the very least labelled a standard.

What do you think?

Also, should we intend to completely eradicate the opaque messaging
channel from Mir in future, then I think we should enable extensions
on top of the standard client/shell protocol. This is mainly to leave
an open door for 3rd party shell developers, to prove that Mir is not
just designed to satisfy Unity8's requirements, but is a flexible yet
powerful foundation for their own display server.

- -Gerry

Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the Mir-devel mailing list