Accessing remote devices

[Havoc Pennington]

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.

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?

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.

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.

Havoc