That also could tie in with another request mentioned earlier: allow
multiple X users simultaneously on the same machine (ala winXP). The
cross connections of "where can I move this window to" now could
involve moving from User1 @ MachineA to User2 @ MachineB, or any other
such combo.
In response to those questions above though, the window warp shouldn't
have to break the X connection if the TCP connection has to be broken.
The X protocol rides on top of TCP (or whatever base protocol you're
using). A warp can be accomplished if Xlib sets up a 2nd TCP
connection, this time to another X server (who thinks he is the only
server displaying this window), then close the first TCP conneciton.
You should even be able to implement an X-window client broadcast this
way! The client (actually Xlib) could open many TCP connections to
different X servers and wait for various DRAW commands from each
server. Of course user interaction should only be allowed from one
server at a time, the DRAW commands are a kind of read-only requests.
Imagine a company message broadcast to all X-servers...nothing stops
the user from closing or minimizing the window....but the message
could be anything from a text message to a streaming video. I'm sure
even online school courses could benefit from this broadcast
feature...the core application doesn't need to know where all the DRAW
requests are coming from, it would just think that the "single remote
user" is rapidly hiding and unhiding various portions of the window.
I invision this example scenario for warping windows (from a purely
user-friendly perspective, not trying to be ignorant of command line
tools):
Say I have some future version of KDE/GNOME that supports window
warping installed on machines A (my linux box in my office), B (my
linux box in the lab down the hall), and Z (my headless linux box
application server...not running X server).
I fire up machine A and log in as user1, telnet to machine Z and type
something like:
export address@hidden
some-x-application
signalling it to start an application and display it on "machine A,
default display & screen on session owned by user1". This app asks the
Xlib to open the connection, in the same way it has in the past before
warping came to be. The Xlib will attempt various authentication
schemes when connecting to machine-a as user1. Once authorized, the
app will do it's normal thing and send the proper drawing instructions
to machine A.
Now, for whatever reason I have to run down to the lab for an hour.
While I'm there I realize I need access to the application already
running on machine A. I go to machine B, log in as (or switch to)
user1. I fire up my KDE/GNOME utility "grab window", and it can ask me
for the target machine name (the one currently holding the window), or
maybe it will do an X broadcast to search for valid X servers that
will let me grab windows. To determine what to grab the utility
connects to machine-A, authenticates me as user1, then queries the
machine for all the windows it's currently hosting under sessions
owned by user1, and asks the server to query each of those windows
asking if it is capable of warping (ie. support the X11 warp
extension). I am then presented with a list of warp-capable
candidates, of which I can select one or all.
For each window I grab, machine A sends a message to the application
(via the X warp externsion) telling it to go ahead and "warp" to
machine B, giving it all the credentials it needs (infomation it
received from machine B itself). The application (er, actually the
Xlib) running on machine Z spawns a 2nd TCP session, this time it
connects to machine B, and authenticates with it using the credentials
it received from machine A. The application then sends a "success"
message back to machine A and closes that TCP connection. Machine A
tells my "grab window" utility about the success, and about the same
time I'll see remote window show up on my session.
Phew, that's a long description, but it shows how possible this is.
The only problem left to solve is: what would happen if machine A dies
while I'm in the lab? Well, normally the application will shut down
when the TCP connection is broken, but what if we change that
behaviour? Instead, since this is all work done in the Xlib on machine
Z, a closed TCP connection forces a "warp" to a local socket on
machine Z. The application is put to sleep while the Xlib waits for a
knight in shining armor to...well...to adopt it.
This could either be from a dedicated "warp server" daemon running on
machine Z, that my "grab window" utility could connect to, or it could
be a simple command line utility on machine Z that probes all open
sockets owned by my application. Either way, once the socket is
located, it is used to deliver the "warp request" message to the
listening application. The application, again I mean Xlib, responds by
opening the connection to machine B, authenticating, and then closing
the socket! A lost X connection revived, Ta-Da!
All this work can be transparent to the application. X clients using
Xlib don't know what machine they're displaying on do they? Why should
they be informed that they were just warped somewhere?
Tyler