[sane-standard] SANE abstraction layer (sanei2)

[Jochen Eisinger]

Hi,

recently I thought a bit about sane2 and came to the conclusion that the
next standard should include an abstraction layer, which does not only
abstract the hardware interfaces (like sanei_usb, sanei_scsi, etc..),
but also all other 'features' of the underlying operating system -
basically what sanei is about.

In my opinion, the current sanei has two short-comings:

  1. it doesn't abstract enough parts of the underlying architecture:

  it is not enough to port sanei, if you want to port sane to another
  architecture. a good abstraction layer, however, would allow for
  exactly this.

  2. sanei isn't used consequently by all backends

  there are still backends using libieeee directly instead of using a
  sanei wrapper for it, etc..

I think we should fix these problems with sanei2. The sanei2 would
include not only hardware abstraction, but also a layer that abstracts
the operating system (think of process handling, but also of config file
 paths etc). And, it should be mandatory to use sanei provided functions.

This has several advantages. First of all, using a unified interface for
access to devices, configuration files, etc.. perhaps allows for a
decent configuration tool (finally) Next, porting sane to another
architecture should be relatively easy, given a c compiler, a basic libc
and a ported version of sanei.

Anyway, I'd suggest to include the following for big interfaces into sanei2:

1. Hardware interfaces (SCSI/USB/PP/(serial?))
2. Operating system (file locking, process management, ipc, dll loading,
(networking?))
3. Configuration (config files, firmware files, calibration data)
4. Core functions (image formats (like jpeg), auth, debug output, stuff
like constrain_value, maybe encryption?)

If I'm not mistaken, these functions should be enough to write a sane
backend that will run on any architecture for which sanei2 exists,
without the need to modify the source of the sane backend.

maybe a short teaser at the end: think about having a stable sane
abstraction layer for win32, packaged as a .dll under some maybe
lgpl-like license. A scanner vendor could then write SANE2 compliant
scanner drivers (possibly still with a TWAIN frontend, implementing
their own version of the sane2 interface, which is public domain) and
using our sanei2.dll for accessing the hardware. The vendor would get
for free (a) support for his scanner on various win32 versions and (b)
support for his scanner on various other operating systems, without
having to change the source. even a binary only backend for linux would
be possible.

comments? :)

kind regards
-- jochen