Accessing remote devices
bhards at bigpond.net.au
Tue Feb 3 08:27:56 EET 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 3 Feb 2004 16:30 pm, Robert Love wrote:
> On Tue, 2004-02-03 at 16:19 +1100, Brad Hards wrote:
> > I think it might be better to bridge HAL (or perhaps at the D-BUS level?)
> > to an existing, working, secure, well-designed service discovery system.
> > Lots of people have done service discovery, mostly not very well. Normal
> > complaints are that the service discovery system doesn't provide the
> > right level of functionality, or that it causes way to much network
> > traffic.
> > I suggest Service Location Protocol v2 (RFC2608, RFC2609, RFC2610,
> > RFC2614 and a few others).
> So you are saying basically what I said, except that HAL itself should
> listen for the service discovery messages? I guess my opinion of that
> depends on what else the service discovery system has to do.
My understanding of the exact relationship between HAL and D-BUS isn't that
clear. As I understand it, HAL is mostly a provider (over D-BUS) of
configuration/status change information to interested parties (for example,
kooka might want to know that a USB scanner has been plugged; similarly
kprinter might care that a USB printer has just been plugged in, so in each
case HAL provides an appropriate D-BUS message).
In the scanner case, if the scanner is plugged into a thin client on the desk,
and kooka is running on a server, we need to get two bits of information from
the thin client to the server:
1. That the configuration (in an area of interest) has changed - there is now
a scanner available.
2. How to connect to the remote (from the perspective of kooka running on the
server) scanner hardware (eg. what protocol to use, what port number,
perhaps some authentication information).
Note that the second bit of information needs to be resolved irrespective of
the first one (ie just because the scanner was already plugged in when kooka
was started doesn't mean we don't need to be able to query for it).
> If it has other responsibilities (which I suspect it does), I would
> prefer it be separate, and bridge to D-BUS, which HAL can then
There are two sides to this :)
1. HAL (or equivalent hotplug abstraction) running on the thin client needs to
flag the change to the SLP server (over D-BUS?)
2. SLP client running on the other end needs to detect the SLP announcement
(or perform SLP query, and receive SLP response), and notify that to
applications (over D-BUS?). Not sure if HAL needs to be involved here - the
state is essentially held in the SLP server on the thin client (plus usually
a local cache).
Does this make my concept any clearer?
BTW: Havoc - your talk about D-BUS at linux.conf.au 2004 didn't make the role
of HAL very clear. Please come back to linux.conf.au 2005 to make up for it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the xdg