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

Thu Dec 12 10:11:15 UTC 2013

On Thu, 2013-12-12 at 10:34 +0100, Thomas Voß wrote:
> On Thu, Dec 12, 2013 at 5:46 AM, Christopher James Halse Rogers
> <raof at ubuntu.com> wrote:
> > On Thu, 2013-12-12 at 10:01 +0800, Daniel van Vugt wrote:
> >> "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* thought I was agreeing with the Simple/Simplistic method :). When
> > Alan brought up his stub implementation of Half-arsed it provoked a
> > further round of discussion, leading to here!
> >
> >> 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.
> >
> 
> 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.

In part because we intend to *not* own every part of the stack - you
reiterated at the sprint a the goal is for Mir to be a generally-useful
library for writing display-server-compositor-shells, not simply a
unity8 subcomponent.

In part because we think there are things which need to be Mir-mediated
because they involve concepts like Surfaces, but which are Unity8
specific.

In part because we want to Mir to have a long and prosperous life, and
X11's extension mechanism is what allowed X to survive for 30-odd years.

>  If it's an issue of unaligned development pace, we should rather fix
>  the process as opposed to decoupling Mir from what Unity8 needs.

I don't think this *is* decoupling Mir from what Unity8 needs; it's
providing what Unity8 needs in a more flexible way.

> 
> > I think we are, and have been, conflating a number of separate issues
> > here.
> >
> > One is “what link-level IPC mechanism should we use? Sockets, shm, etc”.
> > We're currently using sockets+asio.
> >
> > One is “what message serialisation mechanism should we use? Protobuf,
> > Cap'n'Proto, Wayland, etc”. We're currently using Protobuf.
> >
> > A third is “what IPC interface definition language should we use?
> > Protobuf, Wayland, home-grown, etc”. We're currently not using *any*
> > IDL. For the bits where we are using an IDL we're using Protobuf's
> > descriptors, but we also have knowledge baked into the code - fd passing
> > because Protobuf just doesn't support that, and MirEvent, because of
> > reasons that I'm not aware of.
> >
> 
> Let's fix it in one place in Mir then. MirEvent is a POD that was only
> meant to communicate input events, it was never meant to carry over
> arbitrary events to the client. This approach was triggered by our
> choice of input stack. Btw., protobuf offers an IDL and a DDL. I'm not
> sure why you think that we are not using it.

We mostly use it, but we've gone outside protobuf in a way that means
mir_protobuf.proto is no longer a description of the interface.
Specifically, there's Event which is entirely opaque, and there's Buffer
which has ‘oh, by the way, there's stuff not in this interface’ field in
fds_on_side_channel.

If protobuf was expressive enough to use as our IDL we'd have a
‘repeated fd fds’ field and no fds_on_side_channel.

> 
> > I don't mind if we continue to use Protobuf for our serialisation, but
> > an extension mechanism needs an actual IDL. Which could be as simple as
> > extending Protobuf; I don't mind.
> >
> 
> I guess it's less a question of IPC or serialization framework, but
> more a question of: Why do we need to support arbitrary extensions
> when we own the complete stack? In my understanding, this is a
> contradiction. With our conversation at the sprint in mind: I think we
> want an easy way to internally extend the protocol, that takes away
> most of the tedious boilerplate generation by hand. Is that correct?

We want that, yes.

But I think we do also want a general purpose extension mechanism,
designed in such a way that we can easily fold extensions into core
should we decide that they're useful in the general case.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131212/d080dbb7/attachment-0001.pgp>