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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
