[Xcb] Support for saving client's state

[Jamey Sharp]

On Sun, 2005-09-11 at 15:25 +0800, Bernard Blackham wrote:
> I was looking around at implementing support for keeping track of a
> client's X state inside Xlib so that when the X server dies, Xlib
> can, instead of crashing out, decide that it might hang around a
> while to see if the server comes back and reconnect, or allow
> reconnecting to a different server.
> 
> Someone then pointed me at xcb and mentioned that at least somebody
> had the idea of implementing this for xcb. Has any work towards this
> taken place, or would such a feature be a welcome addition? I'd be
> happy to devote some time towards this (in the hope of being able to
> CryoPID[1] X applications).
> 
> Gtk+ has support for migrating windows between displays, but you
> can't yet close the original display (though that bug is targetted
> for the 2.10 release). However, doing it at the Xlib/xcb layer would
> allow it to be toolkit independent.
> 
> I'd appreciate anybody's thoughts on the issue.

My initial thought (after wondering why JG hasn't responded to your
post, as keen as he is on migration/replication) is that I'd be
interested in seeing a more detailed proposal. I'd take working code as
a substitute, of course, but I'm not picky. :-)

For your use case, all you care about is migration, which is "easy".
Since toolkits already know how to deal with a single X pipe, it doesn't
take much hard thought to swing that pipe around like under-funded
firemen at a four-alarm fire to spray it at different X servers one at a
time, and can be done at a number of different levels (app, toolkit, XCB
or Xlib, proxy). Though if any connection setup properties change, such
as server byte order, or whether SHM or other extensions are supported,
you might be screwed.

But I'd really like to see replication too, which involves a lot more
thought, and fundamentally only makes sense at higher levels (app,
toolkit) which allow displaying different state on each display. (See
spellcast and emacs for the two examples of app-level X replication that
I'm aware of.) Replication could also be implemented in a proxy server,
but that can only produce an exact replica of the client's windows on
each connection and has tricky input handling issues. Notice that if you
can replicate onto a second display and then close the first one, you
get migration for free; and since good replication implementations will
be able to deal with different screen sizes, color depths, extension
support, etc., they'll automatically support migrating between wildly
different screens (say, between my 1400x1050 24-bit laptop display with
RENDER and a 320x200 4-bit gray-scale PDA without even SHAPE), which may
be impossible without toolkit help.

Anything done at the level of XCB or Xlib is equivalent to implementing
it in a proxy server, modulo the slight extra effort to execute another
process at session start-up (and the unfortunate fact that it apparently
won't work with CryoPID yet). For all Xlib's bloat, it doesn't have any
more semantic information about the X protocol it's processing than a
proxy server does, and of course XCB doesn't either. Working in a proxy
server keeps the development independent of XCB's development, lets you
support even 10-year-old statically linked binary-only apps or whatever,
and keeps you focused on the issues of connection migration instead of
worrying about how to integrate into an existing library.

So I have two conclusions here:
     1. Migration is a good start, but if you do it below the level of
        the toolkit the effort will be wasted when toolkits have support
        for replication, from which migration follows for free.
     2. If you really want to implement migration in XCB, I want to see
        a proxy server prototype reach maturity first.

But I'm open to arguments.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050914/dbbc9632/attachment.pgp