[sane-standard] SANE abstraction layer (sanei2)

[Enrico Weigelt]

* Jochen Eisinger <jochen at penguin-breeder.org> schrieb:

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.

What things exactly do you have in mind ?

<snip>

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

Please more in detail ?

If you think about interfaces - these are normally jobs for other 
libs, ie. usb handling is AFAIK done by libusb. 

For parport stuff we could just write an libparport (but please, 
please also as an separate project like libusb is) and we're done
at this part. (of course someone will have to port libparport)

<snip>

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

heh ?! you wanna put process control stuff into sanei ?
can't we just rely on posix and require an proper libc on all systems ?

<snip>
 
> Anyway, I'd suggest to include the following for big interfaces into sanei2:
> 
> 1. Hardware interfaces (SCSI/USB/PP/(serial?))

Should be done by separate libs, as already done by libusb. 
These things are not only interesting for sane, but for many other
projects. We shouln't give away the opportunity to concentrate efforts.

<snip>

> 2. Operating system (file locking, process management, ipc, dll loading,
> (networking?))

File locking: 	what's wrong with the flock() api ?
Process mgt:	what's wrong w/ posix ?
IPC:		isn't there an universal lib for that ? otherwise let's 
		invent some. of course as a separate project.
dll-loading:	libdl ? 
networking:	bsd socket api should be available on all interesting
		systems, or if not should be *made* available.
		
> 3. Configuration (config files, firmware files, calibration data)

Whats platform dependent here ?

> 4. Core functions (image formats (like jpeg), auth, debug output, stuff
> like constrain_value, maybe encryption?)

Image encoding is not the job of the sane core. libjpeg will do this fine.
If we wanna support multiple format, we should choose an suitable 
wrapper library (ie. something like gdk-pixbuf, but w/o glib bloat)

<snip>

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

And you wanna allow them to poison the sane world w/ proprietary drivers ?

I'm absolutely against this. Almost for the same reasons why I'm 
against proprietary kernel modules. 

a) security reason: 	never trust an binary. you've got no chance to 
			know comes on board.
			
b) technical reason: 	binary stuff fits only rarely on such flexible
			and thus differing systems like GNU/Linux
			(I consider the lack of an constant ABI as an
			big advantage) do not work reliably. Either you 
			have to make too many restrictions on the target 
			systems (ie. runs on some major distros, but
			not on self-compiled stuff) or the vendors had
			to supply countless of different builds.

c) social reason:	the availability of ready-to-click (TM) drivers 
			reduces the preasure on the hardware vendors to 
			open specs to the opensource community. today
			GNU/Linux users choose their scanners by sane's
			compatibility list. unsupported products simply 
			cannot be sold to (continously growing) penguin 
			folks. this provides some kind of market cleanup.
			the oss community has proven much more reliability
			and better support on hardware drivers (as long
			as specs are open) than propiertary stuff will
			ever have. I'm not happy with the idea to open
			doors for poisoning our software quality with
			proprietary shit when preasure is taken away.
			
BTW: if it goes so far that (technically) stupid ABI layers are 
fizzed in (as already seen on several kernel drivers, which of 
course aren't part of the offical tree for very good reason), 
just to make it easier for proprietary stuff, this will be the
day when I'll do a forkoff removing this shit again.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------