[sane-standard] RFC: SANE2 standard should be seperated in three parts

Jochen Eisinger jochen@penguin-breeder.org
Wed, 08 Sep 2004 16:20:24 +0200


Hi,

I talked about this some time ago with Julien and Henning on IRC, and I
decided to bring this up for public discussion.

This isn't so much about details as how to support buttons on the
scanner or stuff, more the general structure.

Currently the SANE standard mainly defines an API for the libsane. This
I'd call this the SANE2 API. The current standard also defines a network
protocol.

This would be the first major difference. I think the network protocol
should be a seperate standard (and it should be totally redesigned),
let's call it the SANE2 Network Protocol. First of all the network
protocol is of no interest for a somebody writing a frontend - after all
it shouldn't make a difference whether the scanner is attached locally
or remotly. And then the network protocol is quite complex and
unneccesarily bloats the sane api standard. In a redesign different
issues can be addressed: timeout problems, security, multiple users etc..

Last but not least (and this is the biggest difference), the sanei stuff
should be standarized: each backend (and probably meta-backend too)
should be made using sanei functions to access all

o hardware (usb/scsi/parallel port/whaever there is)
o file IO (loading firmware/calibration data)
o configuration files (that's not neccessarily stored in files)
o network IO
o operating system resources (like pipes/processes/signals)

Therefor these interfaces have to be extended (some of them already
exist) and need to be standarized. Currently the existing interfaces are
only documented. Why do I think they should be standarized? Because
these interfaces should not change very often (or better not at all)

Let's call this SANE2 Host OS Interface. With this standard the
following was possible:

o SANE2 can easily be ported on a new operating system, since only the
sanei has to be ported

o we can maybe win more hardware manufactures to provide SANE drivers,
since they'd only need to write one driver for all major operating
systems then. With libsane running nativly on windows, it was even
possible to easily provide a TWAIN driver based on SANE.

o with unified ways to access files/hardware/configuration data, it is
easier to setup and use SANE - currently all config files differ, one
backend supports this, the other only that, etc..

hmyes, that's it. To summarize it:

 - SANE2 API Standard: roughly SANE standard without network protocol
 - SANE2 Network Protocol: the network protocol
 - SANE2 Host OS Interface: extended & standarized sanei

Any comments?

kind regards
-- jochen