Shell communication channel: simple, half-assed or fully-arsed?
Christopher James Halse Rogers
raof at ubuntu.com
Wed Dec 18 03:01:04 UTC 2013
On Tue, 2013-12-17 at 14:56 +0000, Alan Griffiths wrote:
> On 16/12/13 01:39, Daniel van Vugt wrote:
> > I assume you're not talking about exposing the fact that Mir uses
> > protobuf to shell+toolkits? You still mean hiding extendability behind
> > a library, right?
> > I'm still mostly trying to not have an opinion on this thread, but to
> > break the information hiding we have now and expose the underlying
> > protocol library to the shell or toolkit sounds like a bad idea.
> > Information hiding is useful.
> It is a private interface that can be used to develop new protocols at
> the level of unity-mir/platform-api prior to migrating them into Mir.
Expanding on this, it's explicitly a prototyping interface, and
approximately the cheapest possible prototyping interface that allows
It'll go away the moment we have a more solid solution implemented.
> > On 13/12/13 19:33, Alan Griffiths wrote:
> >> On 12/12/13 12:35, Thomas Voß wrote:
> >>> This could quite easily be implemented on top of:
> >>> https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.dynamic_message
> >> Summarizing discussion from hangout...
> >> The use of a definition language and code generation isn't a short term
> >> option - but is nice for the future.
> >> Short term we're going with:
> >> Mir client and server provide a "-private-def" package with C++
> >> interfaces into the communications protocol that allows shell+toolkit(s)
> >> to pass arbitrary protobuf messages.
> >> This will allow unity8/platform-api to prototype and refine interfaces
> >> before they are migrated into the core Mir APIs
> >> This mechanism will need some methods for identifying and transmitting
> >> FDs across the socket (e.g. a special field name.) This is something
> >> that was not allowed for in the raw buffer approach described in the OP.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Mir-devel