Accessing remote devices

Brad Hards
Tue, 3 Feb 2004 17:27:56 +1100

Hash: SHA1

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=20
configuration/status change information to interested parties (for example,=
kooka might want to know that a USB scanner has been plugged; similarly=20
kprinter might care that a USB printer has just been plugged in, so in each=
case HAL provides an appropriate D-BUS message).=20

In the scanner case, if the scanner is plugged into a thin client on the de=
and kooka is running on a server, we need to get two bits of information fr=
the thin client to the server:
1. That the configuration (in an area of interest) has changed - there is n=
a scanner available.
2. How to connect to the remote (from the perspective of kooka running on t=
server) scanner hardware  (eg. what protocol to use, what port number,=20
perhaps some authentication information).
Note that the second bit of information needs to be resolved irrespective o=
the first one (ie just because the scanner was already plugged in when kook=
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
> intercept.
There are two sides to this :)
1. HAL (or equivalent hotplug abstraction) running on the thin client needs=
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=20
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 usuall=
a local cache).

Does this make my concept any clearer?


BTW: Havoc - your talk about D-BUS at 2004 didn't make the ro=
of HAL very clear. Please come back to 2005 to make up for it.
Version: GnuPG v1.2.3 (GNU/Linux)