Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules

[Tyler Hall]

>> G-LiTe / wrote:

> Tyler Hall wrote:

<snip>

> > 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.
<snip>

> > 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
>
>
> That is sortof what I was having in mind. It still doesn't really 
> answer my questions though:
> - Where are we getting the addresses from? The gnome utility would 
> have to know what X servers are running unless you want users to type 
> in the address.
> - Would we allow the application itself to control (part) of this? 
> Some Xlib functions for it?. The way I explained it above it's handled 
> fully in Xlib.
> - How are we going to redraw the contents on the other X server? Is it 
> possible to just send an expose event for the entire window? Or would 
> we have to resend the current state of the window? There's two ways to 
> do the latter, entirely on Xlib's side or the X server extension 
> contacts the other server (in which case the other server needs an 
> extension for it too) and sends a bitmap over.

Perhaps I shouldn't have buried my answers so deep, have a look at the 
paragraphs I've left from my original post. Let me clarify:
Like someone else mentioned in their response, there will be few cases 
where you won't know the machine you want to grab windows from. But even 
if you didn't know it, or were too lazy to type it in, there are several 
solutions I can think of off the top of my head: Bookmarks, master lists 
(databases), or even broadcast. One of the enhancements to the Xserver 
could offer a "browse service", much like the samba server provides. 
Clients (apps) would send an X11 broadcast to the network asking for X 
servers. There's already a similar service for X logins, I haven't 
played with it much, but XDCMP (was that the acronym?) searches for 
valid XDM's on the network and lets you select one from the list to log 
into.

For the 2nd question, I don't think an application should even care 
about being moved to another server, for the same reason it doesn't know 
if it was executed to display on the local machine or a remote machine.

The 3rd response is somewhat the same, if you move a window completely 
off the screen (drag the title to the bottom) and bring it back up, the 
application has no idea what just happened, only that it was asked to 
redraw it's entire contents via a callback from the Xlib. Warping a 
window to another server should work exactly the same. The Xlib within 
the client opens the TCP/IP connection to the 2nd server, which DOESN'T 
KNOW the window is warping over because it thinks the application is 
just starting up and wants to display to its screen. At this point the 
*Xlib* in the client closes the 1st TCP/IP session (so the 1st server 
says good-bye and erases its window) and notes to itself to direct 
further draw responses to the 2nd connection. Well it just so happens 
that the 2nd server says "welcome to my screen, please do a full 
re-draw" which it considers the "initial draw". All this time the 
application itself has been dormant because it hasn't received any 
callback requests (draw requests). Finally when this 2nd Xserver says 
"full draw" the Xlib calls the application's callback and the 
application does it's normal thing.

Tyler