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

Henning Meier-Geinitz henning@meier-geinitz.de
Mon, 11 Oct 2004 18:32:05 +0200


Hi,

On Wed, Sep 08, 2004 at 04:20:24PM +0200, Jochen Eisinger wrote:
> 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.

Well, my response is very late but I guess it's better then nothing :-)

I completely agree to the proposed split of the SANE standard.

> 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..

When the net standard is redesigned, we should make it also more clear
and complete. At the moment it's not easy to reimplement it without
reading header files (and even code).

> 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)

Maybe we should also think about a way to store device ids (e.g. USB
vendor/product ids) in a unified way and avoid listing them in several
places (code, .cond, .desc, .html, libsane.usermap).

> 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)

Should this be a binary interface? In this case me need a real library
that is installed in the system.

> 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..

Options will still be different as the necessaty depends on the
hardware and backend. But you are right, we don't need thre ways to
specify a scanner's device file name.

Bye,
  Henning