dbus and kde on terminalserver
wilhelm.meier at fh-kl.de
Wed Jun 14 05:32:51 PDT 2006
> >O.k., this scenario isn't very useful, but we want to use it in the
> > future with gentoo-diskless-terminals. There we need to transport the
> > client dbus messages to the server dbus to the right session. Is there
> > a way to do that?
> No, nor is it in our plans, AFAIK. You'll need to relay them yourself if
> you need that.
> But I don't see the point in accessing hardware information for hardware
> that applications can't access. It only makes sense to have HAL for the
> local system (even if "local system" means the remote server, not the
> machine the user is sitting in front of).
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.
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.
This would require that the kde-session, e.g., listens to the session-bus,
which is actually not the case, afaik. But I will ask the kde-people for
> >I read about remote messages in dbus. Is this already usable?
> Yes, but it's not what you think. It means two applications can talk to
> each other. Technically, it's also possible to have a session or a system
> bus over TCP sockets, though.
Sounds that this still would be useful for the above situation, since
thin-client and terminalserver are logically tied together, no?
The LTSP-people do something similar, but without using hal/dbus I think.
email: wilhelm.meier at fh-kl.de
More information about the dbus