On Thu, 14 Dec 2006, Giuseppe Sacco wrote: > Hi Gerard and all SANE developers, > > Il giorno gio, 14/12/2006 alle 13.40 +0100, Gerhard Jaeger ha scritto: > [...] >> But I think you are right, we are moving into a dead-end. We have >> devices that are able to do much more than we are able to support >> with the SANE 1 standard AND we have a not yet finished (if finished >> ever) SANE 2 standard. >> >> I'd like to hear/read some more opinions on that. >> Any?
i would vote for re-openning the discussion of SANE2, and begin a project to port a limited number of backends forward. use a whole new SONAME, such that sane1 and 2 libs can co-exist for awhile. many backends will never be ported to sane2, because the scanners have not been made in 10+ years, and there is no-one to do it. my personal list of things other folks have mentioned: 1. i hate threading/forking in backends. it makes debugging a mess, and there are plenty of non-interactive uses for sane that dont need it (the single most popular front-end, scanimage, for one :) As per recent discussions on this list, any frontend that cares about non-blocking, has already implemented a threading solution to deal with all the backends that block. lets drop the non-blocking functions. 2. network protocol overhaul- this keeps coming up, but i dont understand it fully. 3. stackable/modular compression libs- lots of scanners give back jpeg as their native format, and we usually open it up to a huge pixmap, just to hand to front-end. this is esp. noticable over saned. zlib, jpeg, what else? 4. inconsistent option names and arguments between backends. 5. inconsistent gamma/brightness/contrast implementations (sanei_gamma i have been playing with here) 6. persistent device naming. none of this libusb:xxx stuff, i want the backend to provide the name, using something like serial number, rather than using the sanei_usb name. 7. inconsistent conf file layouts- i actually would like to see something more like samba.conf, with [sections], etc. 8. inconsistent debug levels. not that big of a deal i guess. i would rather that they were a bitmask instead of a linear progression. 9. i HATE the frontends changing br-x/y and tl-x/y into t/b/l/r- i have a front-end that takes cli args like scanimage, and i have to do the same option manipulations so that users can use their scanimage commands in my prog. it also means that my back-ends provided help text for those options is not useful. 10. button support. getting better, but not there yet. comments? allan -- "so don't tell us it can't be done, putting down what you don't know. money isn't our god, integrity will free our souls" - Max Cavalera
