Scanner infrastructure in freedesktop

[Donald Straney]

> I agree, SANE is the main (by far, i'm even implicated in SANE) scanner
> support for Linux and most UNIX systems. However, one of the main goals
> of TWAIN 2 is Linux/Unix port. So there might one time a need for other
> backend.

Isn't TWAIN a Windows library?  I guess I can't see the point in
adding yet another API or abstraction layer, since we've got SANE
already.  As I said before, in my opinion if we've got a good (and
standard) system then it's better to merge in improvements from other
projects instead of replacing it each time there's a new one that's
slightly better in some way.  Is there any significant advantage to
TWAIN?

> That's easier, of course, but where is button handling ? hotplug ?
> (easy) sharing ? We need some kind of daemon. Luckily, Martin Owen is
> working on HAL scanner support. But we still need some "middle" software
> between drivers and end user gui. Gui must not load drivers them
> selves !!!

Right, that's why I thought SANE should have dbus support so it can do
that in the backend.  It could do all that with a library, but having
a scanner daemon might make it easier to do the stuff you mention and
would be fine as long as it's run on demand (the typical desktop has
way too many daemons running as it is), and in that case a dbus API
would be more useful.  Honestly, I really like the idea of a dbus API
(adding endpoints on the system message bus is much more flexible than
adding calls in a new library), I just thought that there wasn't much
use for it since linking to libsane was a simpler way.  But if there's
a daemon running to keep track of scanners, button press events, etc.
and SANE is used more as the backend, then I'm all for a dbus API, as
long as everything is kept as simple and straightforward as possible -
otherwise it'll turn into something like the mess we've got with
printing (n+1 libraries, daemons, and abstractions on top of
abstractions on top of even more abstractions).

> Remember that SANE intend to work on WIN32, OS X, Linux and other UNIX.
> The bad thing in this is that, instead of modularize detection and
> sharing, they reinvented their own systme which leads to the current
> situation …

Ah, thanks for bringing that up, I didn't know it was supposed to be
portable.  That changes things a bit, but then it should just have a
set of Linux/BSD routines which interface with HAL and dbus, a set of
Windows routines which interface with the Windows hardware system,
etc. just like you said in fact.  I'll have to download the SANE
source and look over it.  Glad to see someone's already working on
scanner support for HAL.

Donald Straney