barmar@think.COM (Barry Margolin) (03/02/91)
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?
barmarjanssen@parc.xerox.com (Bill Janssen) (03/08/91)
In article <19910301203957.6.BARMAR@OCCAM.THINK.COM> barmar@think.COM (Barry Margolin) writes: > 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. Yes, GNU Emacs xx.xx (for X10) had an interface that allowed this. I've never understood why this isn't a basic capability for X toolkits. The MCC CommonLisp/X toolkit, DWS, certainly allowed this. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
rlk@think.COM (Robert L Krawitz) (03/11/91)
Date: 8 Mar 91 03:34:48 GMT From: janssen@parc.xerox.com (Bill Janssen) Yes, GNU Emacs xx.xx (for X10) had an interface that allowed this. I've never understood why this isn't a basic capability for X toolkits. The MCC CommonLisp/X toolkit, DWS, certainly allowed this. The X folks at the time (1986'ish) thought that it was a really disgusting hack. The implementation was dirty, but it did work and was useful. Unfortunately, to protect against XIO errors, we needed to longjmp out of error handlers and other messy things. It did help me find one longstanding bug in the X driver, though. Something worked properly after an (x-change-display) but not before. It eventually became a simple matter of looking at the reinitialization code to spot the difference. ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)234-2116
bob@MorningStar.Com (Bob Sutterfield) (03/11/91)
In article <JANSSEN.91Mar7193448@holmes.parc.xerox.com> janssen@parc.xerox.com (Bill Janssen) writes: In article <19910301203957.6.BARMAR@OCCAM.THINK.COM> barmar@think.COM (Barry Margolin) writes: I'd like to be able to move my X clients from one display to another... Yes, GNU Emacs xx.xx (for X10) had an interface that allowed this... (x-new-display) is still available under Emacs' X11 interface. It still is neither a general nor convenient solution, such as one might hope from a toolkit-based approach.