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

[Alan Griffiths]

On 12/12/13 09:34, Thomas Voß wrote:
> I don't see why we need a way to extend the protocol. We own every
> part of the stack, top to bottom, and I don't see why the shell would
> need a way to communicate to clients that is opaque to Mir. If it's an
> issue of unaligned development pace, we should rather fix the process
> as opposed to decoupling Mir from what Unity8 needs.

The question I'm trying to resolve in this thread is how much support
for standardising protocols it is appropriate for Mir to provide.

What we've seen over the past months is that unity8 has a lot of
communication with the toolkits that do not represent anything that
matters directly to Mir (or to USC).  The past practice of providing an
implementation of these messages has proven problematic: every time
Unity8 needs a new message passing we get changes in the Mir client API
that are not driven by Mir, just by the need to pass these messages.

There is general agreement that a generic method for passing messages
through Mir is needed, The "poster child" from last week's meetings
being cut-and-paste.

Mir doesn't need to be involved in cut-and-paste beyond passing messages
- any intelligence lies in the communication between shell and toolkit.
While there are good reasons to standardise a cut-and-paste protocol the
Mir project isn't the place to do this. This protocol can develop and
change without changes to the Mir APIs.