Accessing remote devices

[Brad Hards]

=2D----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=
=20
clear. As I understand it, HAL is mostly a provider (over D-BUS) of=20
configuration/status change information to interested parties (for example,=
=20
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=
=20
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=
sk,=20
and kooka is running on a server, we need to get two bits of information fr=
om=20
the thin client to the server:
1. That the configuration (in an area of interest) has changed - there is n=
ow=20
a scanner available.
2. How to connect to the remote (from the perspective of kooka running on t=
he=20
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=
f=20
the first one (ie just because the scanner was already plugged in when kook=
a=20
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=20
flag the change to the SLP server (over D-BUS?)
2. SLP client running on the other end needs to detect the SLP announcement=
=20
(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=
=20
state is essentially held in the SLP server on the thin client (plus usuall=
y=20
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 ro=
le=20
of HAL very clear. Please come back to linux.conf.au 2005 to make up for it.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAHz9tGwwszQ/PZzgRAnveAJ9UUeA1U/P0GVVdAVvo80S20Fb+uQCdFPiy
uKTjowYbeksSXAetAWTJygA=3D
=3DkqqD
=2D----END PGP SIGNATURE-----