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

[Thomas Voß]

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. 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 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.

> 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?

Thanks,

  Thomas

> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
>