handling unknown messages (pt 2 of TODO)

[Kristian Høgsberg]

On Sun, Apr 10, 2011 at 1:47 PM, Iskren Chernev
<iskren.chernev at gmail.com> wrote:
> Hello,
>
> I think I can do the second point in the TODO file:
>
> The message format has to include information about number of fds
> in the message so we can skip a message correctly.  Or we should
> just give up on trying to recover from unknown messages.  We need
> to make sure you never get a message from an interface you don't
> know about (using per-client id space and subscribe) or include
> information on number of fds, so marshalling logic can skip.
>
> So one solution is to include the number of fds in the serialization of the
> message, maybe as a 3rd word in the header?

Yeah, that's the straight forward idea.  I was thinking that we could
be a little smarter about the encoding and use the 16 bits we
currently use for siz a little differently.  Make the upper bit of the
size field reserved, the next three the number of fds and the
remaining 12 bits the size of the message.  That means we're reducing
the maximum message size from 64k to 4k bytes, but that's ok, the
Wayland protocol isn't intended for bulk transfer (send a pipe fd for
that).  The reserved bit must be zero and I'm thinking we can use it
to indicate the presence of optinal header fields.

> The idea about subscription also sounds reasonable, but I don't understand
> what is ment by "per-client id space". After a global object is broadcasted,
> the client may choose to subscribe or not, but I don't see per-client id
> space here (except that the server must maintain for each client what ids is
> he listening to -- maybe that is meant by "per client id space".

The per-client id space has a couple of benefits.  It greatly
simplifies the id allocation (since now the client is in charge of the
entire 32 bit id space) and it means that there's no way a client can
possible address other clients objects.  The subscription step is when
the client assigns a client id to a global object.  With this step in
place, we could even change the type of ids used for global objects to
be something else - strings, for example.  Anyway, this is something
I've been working on, I've just been distracted enough to not actually
finish it for the previous one or two months...

> Also, somewhat related, how different versions of the same interface are
> going to be handled. For example a client only "knows" version 2 of Foo, but
> the server broadcasts version 3 of Foo at some point. So does the client
> subscribe? What if Foo's messages are crucial for that client? Maybe it
> should specify ver 2 in the subscription, and then the sever must make sure
> not to broadcast messages that are not included in ver 2, but then ver 3
> must be backward compatible I guess.
>
> So what do you suggest?

Yup, that's another benefit to the subscription step.  The client can
specify which version of the interface it understands.  The idea is
that interface should always be backwards compatible, clients are
expected to ignore messages introduced in newer versions.

Kristian