[sane-devel] HAL and scanners.

[m. allan noah]

>  > >       * HAL device has a scanner.sane.name string property
>  >
>
> > each backend does its own thing regarding device naming, so this would
>  > require hal to call out to the backend to get the name.
>
>  So this need to provide a function sane_hal_get_device_name(backend,
>  halctx, udi) ?

>  > >       * SANE handle device name like "hal:<udi>".
>  >
>  > then sane would have to query hal to get some device name, then ask
>  > every backend on the system for a list of active scanners, and then
>  > see if one of them matched up with the device name from hal.
>
>  I guess this is suboptimal. Maybe having "hal:<backend>:<udi>" should
>  help.
>
>  In the end, it seems that having backend and udi info is the good couple
>  of info needed in order to compute properly the device id.

you may have a chain of backend names. the udi is only useful if each
backend can use it to get enough info from hal to indentify the
scanner. i dont know what hal can provide in that case.

>  So, we have two possible solutions :
>
>      1. implement sane_hal_device_get_name(haltcx, udi, backend_name)
>      2. handle "hal:<backend>:<udi>" which internally call the above
>         function.
>
>  Which do we choose ?
>
>  > how is hal going to deal with network connected scanners?
>
>  Network discovery is another problem solved by e.g. avahi
>  (mdns/zeroconf).
>

there are scanners (and saned itself) which do not support
autodiscovery protocols. there are scanners which sane supports that
are unknown in the desc files, so would not be in the fdi files
either. both of these would not show up for your program, but work
just fine for users of scanimage or Xsane. now, we dont have to solve
all the problems at once, but i dont think i see what problem hal
integration is trying to solve. can you help me understand?

allan
-- 
"The truth is an offense, but not a sin"