Accessing remote devices

[David Zeuthen]

On Sat, 2004-01-31 at 06:07, Havoc Pennington wrote:
> Hi,
> 
> > 
> > [1] - as I understand it, a fetch TYPE_ARRAY_STRING of method names, and
> > then a slew of PropertyNameGet[Double/Int/Long] type stuff with typing
> > done by strcmps of the name ( perhaps misunderstood ).
> 
> I'm not quite sure why you'd do this; the intent is that on a D-BUS
> object you can call the Introspect() method, which returns an XML
> description of the methods on said object, as suggested by Matthias
> Ettrich. This level of functionality is in the bindings (see
> half-finished GLib bindings), not in the core libdbus.
> 
> I have to admit I haven't looked at the HAL code you are discussing,
> though.
> 
> IIRC my suggestion for how to do HAL was to make each device an object.
> 

Yes, this is how it works today, see 

 http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html#AEN140

for details. 

For clients it's also wrapped in a C library with libdbus as the only
dependency. With the D-BUS bindings for more sophisticated languages
like Python you don't even need this - you'll simply use the network API
as described in the spec - see hal-device-manager.py for an example.

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

Woow, slow down - today HAL only exports a list of device objects with
well-defined properties - it allows applications like
gnome-volume-manager to use the ''simple'' devices like storage because
all the abstraction (e.g. filesystems) is already in the kernel. In
fact, g-v-m simply reads the 'block.device' property and invokes mount
when a new device is detected.

(of course, there are some fstab management that needs to go on behind
the stages, but this is outside the scope of HAL)

If you want to use more sophisticated devices, HAL doesn't really give
you anything today. What have been discussed was to use the concept of
device capabilities with the thinking that a capability isn't
necessarily related to a particular device type / bus / class or
anything. The current proposal of using devices was discussed a few
weeks back

 http://freedesktop.org/pipermail/xdg/2004-January/003238.html

and this proposal says that it's up to the service/library for
capability X to handle remote devices. If no-one objects, I'm going to
add this to the next 0.x.0 release of HAL (which would be HAL 0.3.0).

It seems that what Michael is after, is to standardize how such
capability services/libraries should work in a network transparent way,
or no?

> 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, the HAL service is on the system bus.

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

Correct - note that there are no measures for controlling access to
devices in HAL presently.

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

My thinking was that this could be done in many ways. 

Since there already exist a bunch of software for accessing various
devices building a HAL library for the capability including such devices
would mostly amount to writing an interface and map to the correct
library on runtime depending on the characteristics of the device of
said capability.

(for a practical example, look at the different pieces of software for
accessing mp3 players etc.)

  David