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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
