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

[Alan Griffiths]

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
https://code.launchpad.net/~alan-griffiths/mir/message-passing-api/+merge/198422

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131211/b4146168/attachment.html>