handling unknown messages (pt 2 of TODO)

[Iskren Chernev]

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?

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

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?

Regards,
Iskren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110410/a4baf71a/attachment.html>