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

[Daniel van Vugt]

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.


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