Reconnectable X - improve desktop reliability

[Adam Jackson]

On Tue, 2009-02-17 at 18:01 +0000, Jeremy Sanders wrote:
> I have searched around, but I haven't been able to find out whether anyone 
> has managed to make an X server which was reconnectable by the applications 
> talking to it.
> 
> What I mean is that it would be nice to have all the existing applications 
> carry on running if X dies underneath them. They could then connect to a new 
> server when it became available.
> 
> Perhaps this is an application rather than X.org issue. Perhaps some sort of 
> simple layer could sit between the apps and the server to solve the 
> reconnection.
> 
> Could someone with some knowledge of how this works comment on whether this 
> would be feasible?
> 
> It would really help Fedora reliability if the desktop could survive X 
> crashes. It would also allow the possibility of disconnecting an X session 
> and reconnecting it later (I know vnc and nx allow this sort of thing).

Everyone loves this idea and no one ever does anything with it.  Partly
because it's, shall we say, intractable.

Start with something like xmove:

http://en.wikipedia.org/wiki/Xmove

and then update it to know about all the new object types that have been
introduced into X since it was written.  Then figure out a way to
magically know which X server to reconnect to (hint: "the next one that
starts" is not the correct answer).  And figure out how to make
accelerated 3D work, and perform.  And probably fix drag-and-drop and
startup notification and a few other things that rely on all the X apps
sharing the same view of the X server's XID space.

X does not make this easy.  Few window systems do, for that matter.
It's tractable for something like screen(1) because there's very little
state to keep track of, and there are no handles or IDs that you have to
preserve or map that leak into the text mode API.

In some sense it's just typing, it's possible to write code that does as
good a job of this as you want.  But I suspect that ends up being more
work than just fixing the crashes in the first place.

(More fundamentally: X is a moderately okay rendering API but a terrible
view API.  They happen to be tightly bound, and that makes it really
hard to separate view from control.  One can imagine an X server that
delegates view to some other application, be it Spice/RDP/VNC service or
a locally-rendered compositor, and in this model it becomes much easier
to get arbitrary numbers of views because you're getting them from
something designed to provide views, instead of something designed to be
a local rendering server on a VAX.)

So in short, I think it's a noble but misguided idea, and I'm not going
to work on it, but if someone really wants to apply that much thrust to
the pig I'll be sure to ooh and aah appreciatively while maintaining a
safe distance. ;)

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090217/7754af8b/attachment.bin