[sane-devel] Re: [PATCH] generate hal fdi file

[David Zeuthen]

On Tue, 2007-03-20 at 13:51 -0400, m. allan noah wrote:
> ok, i think i understand the distinction between 5 and 6, you cross
> the system to gui gap using dbus signals between two processes?

That's correct.

> 1. does udev signal HAL on every change to any device in the system,
> or only certain devices?

All devices - some are ignored by HAL though since we haven't made good
abstractions for those.

> 2. what is the advantage to using a HAL 'addon' vs having udev spawn a daemon

That it can plug into the HAL framework - udev doesn't know per se that
some USB device is a scanner; there's no standardized way to query udev
for this unlike HAL where you can do a 

 libhal_manager_find_device_by_capability (hal_ctx, "scanner");

Udev is also the wrong approach for this; of course I'm a bit biased
here (since I'm the HAL maintainer) but fwiw Kay Sievers (udev
maintainer, HAL developer) thinks so too. Also, if you went the udev way
you'd need to do your own IPC and connection tracking; not necessarily
hard but I think it's more elegant just using D-Bus that is already
available, API stable and so on and so on.

That and also..  udev is Linux specific. HAL is part of OpenSolaris at
this point and since they use GNOME too I'd expect them to pick up all
this as well. Same goes for FreeBSD although I must admit I haven't
tried FreeBSD with HAL yet (but I plan to). There would be nothing
Linux-specific about the HAL addon shipped with SANE if this is what we
decided to do.

> 3. what if the scanning app dies without signalling the addon to
> re-start button monitoring?

So this would work because libsane would be patched to open private
connection to the system message bus daemon (e.g. D-Bus) so it can call
into the HAL addon. If that process dies then the system message bus
notices and sends out a NameOwnerChanged signal that we catch it HAL.
This way of "connection tracking" is standard for D-Bus using apps, many
use it (e.g. the screensaver, power management daemon and so forth).

     David