Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!ora!bloom-beacon!dont-send-mail-to-path-lines
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Reattachable X clients
Message-ID: <19910301203957.6.BARMAR@OCCAM.THINK.COM>
Date: 1 Mar 91 20:39:00 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 61

I've recently started using the program "screen" when I login from home
using a dumb terminal emulator.  The primary purpose of this program is
to allow a single terminal to be multiplexed among several sessions,
using pseudo terminals.  One of its other features is the ability to
disconnect these sessions from the original terminal, logout, and later
reattach them to another terminal.

It struck me today that X should be able to do something similar.  I'd
like to be able to move my X clients from one display to another (for
instance, if I had a home X terminal I'd want to bring my windows home
with me), or reboot my workstation without having to kill all the remote
X clients (saving local clients across reboots is outside the scope of
X).  X clients communicate with their server via a "display" abstract
data type; this object hides the details of the communication protocol,
allowing the same clients to work over TCP, DECnet, shared memory, etc.
Thus, it should be possible for them to disconnect themselves from the
transport mechanism completely, and later open a new transport
connection and use that.

Much of this could be implemented transparently within the current X
design.  When the connection to the display is lost, a stub transport
level would take its place.  It would be like a /dev/null that
understands the X protocol; it would never send input events, all output
would be absorbed and discarded, XSync() would return immediately, etc.
I'm sure there are some tricky cases (e.g. display attribute inquiries),
though, but they can probably be worked out.

The harder part would be the mechanism for reconnecting them to a
display.  I suppose the stub could listen on a socket for a message from
the user giving it a new display name, or some interprocess
communication mechanism could be used.  When the new display is
attached, all the clients would be sent Expose events.  Since clients
may encache display attributes, we'd probably need to invent a new event
that tells them that the display's attributes have changed and they
should update their caches.  Additionally, there are security issues
(users should be able to "steal" each others' clients).

One way to experiment with this without changing the current X library
implementation would be to use indirection, like xscope and the programs
that forward X operations to multiple displays (any problem in computer
science can be solved with enough levels of indirection).  Implement an
"indirect X server" that forwards operations between a real display
server and clients.  When the display goes away, or upon receipt of a
particular signal (On Unix, SIGHUP would be appropriate), it would stop
forwarding and implement the stub server functionality until it gets
connected to a new display.  We'd still have to work out some of the
above issues, though.

This wouldn't provide the ability to reconnect different clients to
different displays, but that's probably not an important aspect.  Of
course, you could run multiple indirect servers, initially pointing them
all to the same display, and connecting different clients to different
indirect servers.  Later the indirect servers could be reconnected to
different displays.  Alternatively, a single indirect server could
support multiple screens, and allow each screen to connect to a
different display.

Has anyone in the X development community thought about this before, and
is something like this a possibility for a future version of X?

                                                barmar