dbus and kde on terminalserver

[Wilhelm Meier]

Am Mittwoch, 14. Juni 2006 15:11 schrieb Joerg Barfurth:
> Hi,
>
> Wilhelm Meier wrote:
> > If we assume a client-machine running as thin-client (the thin-client has
> > no local apps nor the user logs into this client) and a terminalserver
> > the user logs in, logically the hardware of the thin-client belongs to
> > the session, the user opens on the terminalserver.
>
> Depending on the thin-client/terminal-server architecture this may not
> be entirely true as well. Sun Ray supports 'session mobility': you can
> detach a thin-client from a running session and reattach to the same
> user session from a different thin-client.

Yes, the session is the object where the ressources the user needs are 
concentrated. Session-mobility also can mean, the session switches from (load 
balanced) server to server ...
The ressources on the thin-client the session needs (devices, display, etc.) 
also belong the so called session, I think. Then, you can attach multiple 
thin-clients and their ressources to a session.

>
> So the thin-client hardware belongs to the terminal-session on the
> server, 

o.k.

> which is distinct from the user login session. 

what do you mean with user login session?

>
> > If the user plugs-in a device, the local hald on the thin-client sends
> > messages to the dbus of the thin-client, which are not recognized (there
> > is no session). Now, one could make the new device of the thin-client
> > available on the terminalserver, for instance via network-block-device.
> > In this case it would be useful to inform the session on the
> > terminalserver of the new device for the session.
>
> Again this is even more pointedly so in the Sun Ray case: the
> thin-client doesn't run a local hald (or in fact any general purpose
> OS). If a usb device (other than mouse/keyboard) is plugged into the
> thin-client a new device is made available on the terminal server. But
> it isn't entirely clear how to do HAL-style notification for this.

That's the point. Ideally, hal would be a distributed-hal. But it isn't. So, 
hal is a concentrated-hal which needs a capability to distribute. My first 
thought was to use dbus to distribute, using the system bus. But we then need  
a publish/subscribe-mechanism for the dbus instances - this could/should be 
solved externally to dbus.

Next point is to direct the messages to the right session. This must be part 
of the ts-software, sure. The kde-approach to use the system-bus is in my 
opinion not the right way. There should be multiple session-busses for each 
session and a message router, which routes the messages from the system-bus 
to the session-bus(ses). 

>
> > The LTSP-people do something similar, but without using hal/dbus I think.
>
> Well, some of the assumptions inherent in a global system bus break down
> in a thin-client scenario, and I believe that in general the session bus
> is an incomplete replacement for it. Session mobility or user switching
> on the thin client a scenarios that expose the need for another scope
> for signal distribution.
>
> - Joerg

-- 
Wilhelm Meier
email: wilhelm.meier at fh-kl.de