[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: weigelt
Subject: Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules
Date: Wed, 27 Aug 2003 20:52:08 +0200
User-agent: Mutt/1.3.27i

On Wed, Aug 27, 2003 at 01:39:06AM -0500, Tyler Hall wrote:

> That also could tie in with another request mentioned earlier: allow 
> multiple X users simultaneously on the same machine (ala winXP). 
This would also nice to have: an X server which can detach from the
console and then go into sleep (freeing all resources not really needed)

Perhaps such things should be done in an local X proxy. We then need
some additional extensions to handle this with high performance.

> 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.
The display IDs must be different. This also must be told to the application
on the other side. 

btw: is there any protocol which allows an client to check if an display
is really the one it wants ?

> 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).
No - the connection has to be completely killed. Perhaps not the one
between the real client and the proxy stuff (which probably may reside
in Xlib), but the one between display and proxy. So you can move around
and even kill the old machine without any impact for the application.

> Of course user interaction should only be allowed from one server at a 
> time, the DRAW commands are a kind of read-only requests. 
Why ? Once we have multiple X connections, we also could allow that
(perhaps we make an switch for that) - this could be really nice 
for teaching: the mentor can attach to any display and do something nice.

> 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. 
Why should we stop him ? It is his decision.

btw: why not implementing some MPEG and audio support in the Xserver ? 
DVD players could try use it first and then fall back to old the method.
I really would like to see such things in the Xserver, since today
much of the hardware also supports that - and i dont like direct access
to the hardware beside the Xserver.

Perhaps we should design an completely new graphics interface framework, 
where the question of display hardware,location,protocol is completely 
hidden behind (a little bit in the spirit of SDL). This interface could
be used inside the Xserver as well as for fullscreen/singlewindow applications.

The application would only see an display which has an textual name. It
may send information of several types (i.e. paint instructions, static
objects, video streams, etc) to the display an receive input data
(keyboard, mouse, whatever)

Several backends may exist - one for direct or fb access, which is also
used by the real Xserver - another for local X, another for remote X, ...
perhaps somewhere win32 or OS/2. In the case of multiwindow environments,
the display may be the whole screen (screen-wide window) or an single
window. Its then the part of the actual display driver, which functions
it implements. The console/fb backend wont support real windows, but
perhaps clipping regions (which also could be accessed as dedicated displays?)

Perhaps this idea looks a little bit like window's DC idea ...

> 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.
Sounds nice. You also could do grab * and fetch the whole desktop.
It would also really be nice to get the windowmanager and other stuff.

> 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.
So you have the proxy functionality in xlib. Wether it is there or in 
an separate process should also be an little config switch (xlib itself
just an dl-loader ...)

> 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.
Unneeded X connections should be killed nevertheless. Why should we
remain it open ? Why shouldnt we allow the application to run completely
headless ? 

> 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?
ACK. It all can be hidden behind normal applications.

 Enrico Weigelt    ==   metux ITS 
 Webhosting ab 5 EUR/Monat.          UUCP, rawIP und vieles mehr.

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     address@hidden
 cellphone: +49 174 7066481          
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]