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

Thu Dec 12 04:32:25 UTC 2013

Thanks for starting this off Alan,

On Wed, 2013-12-11 at 14:00 +0000, Alan Griffiths wrote:
> I'm trying to summarise some discussions around the need for Mir to
> provide a ABI stable channel of communications to shells and client
> toolkits (such as unity8/platform-api) that make use of it. This should
> allow messages to be passed that Mir has no need nor ability to interpret.
> 
> Future nice-to-haves:
>   o consistency between shells and a framework for protocol extensions
>   o some messages to be meaningful to Mir to enable optimizations
>   o Migrating the current API (e.g. attribute setting) onto the same channel
> 
> There are several approaches to this.
> 
> *Simple/Simplistic
> 
> *This is what I've sketched out in
> https://code.launchpad.net/~alan-griffiths/mir/message-passing-api/+merge/198422
> 
> Mir simply punts all concerns about protocol negotiation, versioning and
> structure to the shell and relies on the shell to provide all
> information that Mir will ever need.
> 
> The advantage of this approach is that we can do it without further
> discussion and unblock unity8 work.
> 
> The disadvantage of this approach is that the "nice to haves" are left
> as an exercise for the interested Mir user.

I'd like to add that another disadvantage is that it's pushing the
responsibility for extension discovery, negotiation, and versioning onto
the shells and toolkits. That's non-trivial, and will be common to all
non-trivial shells/toolkits, so should be in Mir.

…
> *fully-arsed*
> 
> Projects like X11 and Wayland have effective protocol definition and
> extension mechanisms. We should build on this - Wayland being the better
> example as it builds on the X11 experience.
> 
> I don't yet have a clear vision of what a successful implementation of
> this approach looks like - and suspect that different team members have
> differing thoughts on how we would go about this.
> 
> *Conclusion*
> 
> I think that we should discuss the fully-arsed and flesh out some
> specific ideas. But as that may not lead to a quick (or any) conclusion
> it is worth implementing the simple approach in parallel so as to
> unblock unity8 development.

I concur; unblock unity8 with the simplest possible thing, then replace
it with something long-term.

In that vein, let's discuss extension APIs.

We need three things:
1) An IDL to define the extensions,
2) A compiler to take the IDL and spit out appropriate code and headers,
and
3) A mechanism in core Mir to handle extensions

== IDL ==
For the IDL we need something more expressive than Protobuf's .proto
files; protobuf doesn't handle our requirement for fd passing, so we've
somewhat awkwardly wedged this alongside (see also MirEvent). This IDL
might be a simple extension of protobuf, or could be something entirely
different. The important things for the IDL are:

 *) Must be expressive enough to cover all the primitives we want to
send over - at least integers, strings, and fds.
 *) Should be expressive enough to handle the types of composites we use
- arrays and structs, primarily.
 *) Should be expressive enough to encode some minimal semantics -
request/response is what I'm thinking of here, but we may want more.
 *) Should support and encourage self-documentation; ideally we'd be
able to generate useful doxygen (or other format) from the IDL.

== IDL compiler ==
This should take the IDL and generate the requisite headers and code to
build a two shared libraries; the server side and the client side. I
like the fact that our interface is the shared library rather than any
particular wire protocol. We should treat extensions similarly.

The actual implementation should be pretty straightforward once we've
decided upon an IDL and core Mir mechanism.

== Core Mir mechanism ==

I've no particular current thoughts on this; we need a server-side
ability to register extensions (possibly multiple versions), and a
client-side ability to probe for them. This seems fairly
straightforward.

The main questions I can think of are: do we want to support the
implementation of multiple different versions of an extension
server-side (probably yes?), and do we want to support probing multiple
different versions of an extension client-side - use case is something
like ‘I can support DnD proto 2 or DnD proto 1, use what the server
supports’ (dunno?)

== Example ==

Here's a quick example of an IDL definition and generated headers. This
is not a proposal for what anything specific should look like. It's
merely intended to illustrate some properties of what a solution should
look like.

Given the example interface definition

/****************************************/
DnD {

version 1;

target surface {

/* Sent by shell when a DnD action targets a client surface.
 * May be sent more than once, with different coordinates.
 * To accept, client must respond with Accept
 */
event "Available" {
        surface_coordinate x;
        surface_coordinate y;
        string             available_formats;

        reply "Accept" {
                string acceptable_formats;
        };
};

}
}
/****************************************/

the interface compiler would generate the following header, and code
behind the header to interface with Mir's IPC mechanism in
libmirclientsurfacednd.so.1:

/***** CLIENT HEADER *********/
typedef void (*mir_surface_dnd_available_callback)(MirSurface *surf,
        int32_x, int32_y,
        const char *available_formats,
        MirEventCookie cookie,
        void *ctx);

void mir_surface_register_dnd_available_callback(MirSurface *surf,
        mir_surface_dnd_available_callback callback,
        void *ctx);

void mir_surface_dnd_accept(MirSurface *surf,
        MirEventCookie cookie,
        const char *acceptable_formats);

bool mir_connection_supports_surface_dnd(MirConnection* conn);

/******************************/

It would also generate the server interface, and code behind it to
interface with Mir's IPC mechanism in libmirserversurfacednd.so.1:

/***** SERVER HEADER **********/

class msh::Surface::DnD : public mir::Extension
{
public:
        void send_available (msh::Surface const& surf,
                             int32_t x, int32_t y,
                             std::string available_formats,
                             std::function<void(std::string)>
                                reply_handler);

};

-------------- 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/eeb1477c/attachment.pgp>