On Thursday 14 December 2006 12:11, Alessandro Zummo wrote: > On Thu, 14 Dec 2006 08:48:38 +0100 > Gerhard Jaeger <gerh...@gjaeger.de> wrote: > > > > > > > I would like to add the format SANE_FRAME_RGBA and have the infrared > > > channel passed back as the alpha channel. I would then patch > > > scanimage to save this channel to a tiff file. > > > sorry for the noise, but AFAIR, we had this discussion already here > > about extending the currently available image data formats. The > > conclusion was, that with SANE 1.0 we should not do that - SANE 2.0 > > will be the solution ;) - Henning??? > > > > I see that your changes won't probably break anything, but I think > > it is again time for the discussion - Allow extending SANE 1.0 > > or not - SANE 2.0 is far from being ever started :( > > I would really appreciate a sane 2, but we have a problem:
Guess we have much more than one ;) > who will write it? who will port the drivers? > > some drivers are old. original authors are not available. > original testers are neither and they might > no more have the equipment. > > I've got 0 (zero) answers to my "call for beta testers" for > the epson2 driver. > > the code must be completely reviewed and each driver > has some code/style standard of its own to handle the things.. > > a complete rewrite could take no less than 1 year if appropriate development > forces (and equipment) are available, which it doesn't seem the case. > (there are open bugs in the bug tracking which are more than > 3 years old). Full ACK. > And that is when development is started, but first we should agree > on the sane2 specs, which could take months. It already took us years ;) > So we either find a way to pay 2/3 developers full time or > I guess we should stick to sane 1 :-D he, he... > So, my opinion is to stick to sane 1, document what we have > at the deepest level (i'm, for one, adding comments to > epson2 in order to explain what's done). > > we can reorganize the drivers, split the code and > add some features (like new frame formats, which > are a quite easy thing and would not break anything) > > maybe add a wiki and a new friendlier bug tracking > system (trac has both). any volunteers? > some things that have been agreed on sane2 can easily > be implemented in sane1 with no/minor compatibility > issues. ACK. > minor tweaks, like agreeing on common names > for scan sources are implementable (ADF vs Automatic Document Feeder). > > so, while having sane2 is a good thing, IMHO we are not at a > point where this can be done. improving sane1 is still doable though > and would be helpful in the path to sane2. > > my suggestions, thus, are: > > - wiki Hmmm, it's like everything around here in the net: * a lot of the information is hopelessly outdated * if up to date, nobody uses it - they ask on the mailing list > - trac > - comments * Good thing, we started usage of doxygen... > - dropping support for anything that is not C99 > - code reorganization (no more 6K lines in a single file!) > - standard debug levels for drivers (no more SANE_DEBUG_DRIVERNAME) > - conformance The same problem as porting the stuff to SANE 2 - you'll need the authors... > and call that sane 1.5 :) > > just my two cents... Only two ;) All of your point sound reasonable and doable for me - of course, but as I said: We ran into these discussion often enough and the result was: No new features, they are for SANE2. 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? Gerhard
