Accessing remote devices

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
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 
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
> intercept.
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?

Brad

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)

iD8DBQFAHz9tGwwszQ/PZzgRAnveAJ9UUeA1U/P0GVVdAVvo80S20Fb+uQCdFPiy
uKTjowYbeksSXAetAWTJygA=
=kqqD
-----END PGP SIGNATURE-----