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

[Daniel van Vugt]

"Half-assed" is inaccurate I think. Under that heading you describe 
what we had already agreed to do (as much as the team can agree on 
something).

I suggest being careful trying to merge the existing areas of opacity in 
the protocol. I'm not sure they belong together.

Protobuf is quite extendable already. Are we not using it in a way 
that's compatible with extension? I'm not a fan of protobuf, and am even 
open to the idea of trying the Wayland protocol, but I don't yet see a 
serious problem with protobuf that needs solving.


On 11/12/13 22: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
> 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.
>
>