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

[Alan Griffiths]

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?

Wrong.

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

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