[sane-standard] SANE abstraction layer (sanei2)

[Gerhard Jaeger]

Good morning ;)

On Wednesday 19 October 2005 23:38, Enrico Weigelt wrote:
> * 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. 

Guess this stuff is already done, either by such libs as libusb, glibc
or systemlibs on other systems.

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

Already done too. Either libieee1248 or for sane: sanei_pp which
tries to do excactly what Jochen wants to have.

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

I think in the end we've already started that, for the hw-interfaces we
have the sanei_usb, sanei_pp, sanei_scsi. 

Also for system stuff like fork/threads we have sanei_thread, for locking
I tried to introduce sanei_access

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

See my comments above - we have this stuff!

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

Guess we need to do some work here, as we want to cover and probably
work around the various incarnations of i.e. POSIX. Also the locking
stuff. 

> > 3. Configuration (config files, firmware files, calibration data)
> 
> Whats platform dependent here ?

Nothing, but we have no common format for config files. FW and calibration
is not that important, as each backend has to handle its format. But the
config stuff should be common. Has been discussed before.

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

Ain't this already done?

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

Hmmm, don't wanna start a flameware, but I'm pretty sure a lot of users
won't care about that. They wan't to use their devices.

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

Nope - see Nvidia, or at least the binary only stuff from EpKowa. The
vendors need to provide some objects/libs which could be used...
AFAIK, Lexmark and Brother also started such a thing...

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

In an ideal world...

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

Oh boy, don't even think about that ;) How would you call that
project: YAS (Yet Another SANE) ;)

On a lot of points I think we already have more or less what
Jochen suggests. We'd like to cover a great variety of systems
and HW buses. And therefore we need to a certain point these
abstraction layers - simply to fixup the differences and make the
underlying stuff behave the same on each OS we'd like to support.

Ciao,
Gerhard