So, I've gone ahead and implemented my ideas as a proof of concept. I still hope that my work can be adapted and integrated into the official Wayland. I have a lot more experience with network protocols than with X11 and OpenGL and friends, so this is what I can do to help Wayland.
I have already described the problems, here is the description of an implemented solution. Please respond with any comments or criticisms. I won't explain too much here, I've done it before and I've basically just tried to solve existing issues with the smallest amount of changes. - Per client ID spaces, except for global objects - Separate server and client ID spaces: clients requesting object creation use positive IDs, the server uses negative IDs, global objects (always created by server) use a sub-range of negative IDs. This prevents ID clashes between server-initiated and client-initiated object creation. - When an object is destroyed, all parties that know about an ID must confirm that they know about its destruction. Only then can the ID be reused without risking ambiguities due to the asynchronous nature of the protocol. (If a client disappears it is assumed that it confirmed all pending destruction events and sent destruction requests for all other objects.) - When a global object is created all clients are informed via the display::global() event and it is assumed that the clients created the local counterpart and are listening to its events. To avoid unnecessary wakeups, clients can either "choke" the server, i.e. tell it to stop sending events, or if they are permanently not interested they destroy the object and tell the server about it. They cannot re-subscribe in that case, due to ID ambiguity issues. The object is not destroyed on the server even when zero clients have counterparts so that a client that is added later can still see it. When the server destroys a global object the usual rule applies that all clients must confirm its destruction before its ID can be reused. The choking mechanism could be extended to all objects (i.e. including non- globals), but just creating or destroying the object as required seems sufficient. I have picked the term "choking" because it is also used in the widely used BitTorrent. - There is a remoteDetached() virtual method on objects that is called when the remote side has destroyed the object or disconnected altoghether. This will mostly be used to destroy the local objects in response, obviously. - Implementation details: objects are linked to a class implementing the IConnection interface. Connection is the usual implementation, and only global objects in the server-side implementation use the BroadcastConnection class that contains more involved logic to handle the one-global-server- object-to-many-client-objects relationship. I'll be available by mail and on IRC to answer detailed questions in case you can't be bothered to read C++ code - it seems that most C programmers don't like C++ and vice versa... The repository homepage is at http://quickgit.kde.org/?p=scratch%2Fahartmetz%2Farea.git clone URL is git://anongit.kde.org/scratch/ahartmetz/area.git Cheers, Andreas _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
