Accessing remote devices
Kiran Kumar Immidi
kimmidi at novell.com
Mon Feb 2 11:06:32 EET 2004
On Sat, 2004-01-31 at 10:37, Havoc Pennington wrote:
> Returning to the original topic of discussion, remote devices; I would
> expect HAL to take care of this behind the scenes essentially, as remote
> devices vary; e.g. printers would use the IPP protocol, or a file share
> might use the CIFS or NFS.
> Of course these examples are a device on server used by client. The
> CD-ROM or sound card on a client terminal, with apps running on server,
> seems to imply that the device list varies by each user logged in to the
> server; which seems to mean we want a per-user device list. Right now
> the HAL usage of D-BUS involves the system daemon which is global to all
> users on the terminal server, no?
Right, and IMHO, this impediment to device access accross the network
has to be worked over.
> So one clear issue is how to architect HAL to support per-user devices.
> Perhaps this is also useful when some devices are access controlled and
> thus not available to all users.
So supposing that the above issue is resolved, applications could
start off by querying for devices of the required capability over the
system bus (accessible from the network?), and get an object reference.
(The interface org.freedesktop.Hal.Manager providing the
FindDeviceByCapability() method to get the udi of the device could serve
as a discovery method).
These "object-devices" could provide the services required of a device
having the requested capability as was discussed previously in these
threads and also by David elsewhere in the current thread.
(The services could perhaps belong to a hierarchy of interfaces
derived from a common base one).
> The other issue is, in the implementation of HAL, what protocol is used
> to communicate between the thin client's hardware and the user session
> on the terminal server; my first step in answering that would be to ask
> how SunRay and similar are doing it already. You could presumably use
> D-BUS in point-to-point or 1-to-1 (no bus daemon) mode for this, but
> there's no real reason you have to use D-BUS vs. some other RPC. Even
> something as trivial as XML-RPC would presumably do the job.
Does this mean a point to point session between the user session on
the terminal server and a piece on the thin client talking internally
over the bus daemon?
Kiran Kumar Immidi
More information about the xdg