Finishing the network protocol

[Andreas Hartmetz]

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