2011/4/11 Kristian Høgsberg k...@bitplanet.net
On Sun, Apr 10, 2011 at 1:47 PM, Iskren Chernev
iskren.cher...@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.
Ok, that makes sense.
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.
So basically, even if you implement the subscription mechanism the number
of file descriptors should be given -- except in the case where the server
knows all previous versions and sends only the messages the client knows of.
Maybe all messages should have the version number they were introduced in.
Kristian
So I can safely implement the passing of the number of fds the way that you
describe it (safely -- I mean it wont be redundant after a few months :)).
Regards,
Iskren
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
