[sane-devel] The future of the SANE-Standard

[m. allan noah]

On Dec 19, 2007 2:30 PM, Oliver Rauch <Oliver.Rauch at rauch-domain.de> wrote:
>
> Am Mittwoch, den 19.12.2007, 19:27 +0100 schrieb Julien BLACHE:
>
> >
> > Would you care to explain why the addition of new frame types
> > would create any such problems ? Because that's the only thing that
> > has been discussed so far - no ABI changes, no new functions in the
> > API, just new frame types.
>
> What is discussed in the moment is a "slow transformation from SANE1 to
> SANE2" (I don't remeber the exact words). And we do not discuss only
> some new frame types. It took about 30 minutes after this suggestion to
> add several other things that are not compatible to SANE1.

And if you would care to re-read the thread, you will see that I shot
down those ideas as soon as they appeared, and have said repeatedly in
this thread that SANE 1.1 will stay backward compatible at the API, by
being limited to only new frame types and new well-defined options.

>
> And what all the people forget is that is may be a simple step to change
> a backend to send a new frame or image type to the frontend.
> For the frontends we get a lot of work to handle this. But here are one
> or two frontend authors that try to discuss with several backend
> authors.

so you would rather do sane2, which would require more work for these
few front-end authors, and more work for ALL backend authors?

> We will get a lot of incompatibilites when we add several new frame
> types. From the backend author's view this is not much work, the backend
> simply sends the data the scanner produces. But the frontend authors
> have to handle this.

its easy- you skip the frames you dont understand! Look at the sane2
standard for a second- it is going to include a SANE_FRAME_MIME! How
is that going to reduce the number of image types you have to support?

>
> Now some people will say that we do not need all frontends to handle all
> frame types. But what is the adavantage of it when the frontends can not
> handle it. It only makes sense to add e.g.  a TIFFg3FAX or JPEG frame
> type when all frontends can handle this. But when we make this step,
> then we should make the complet step to SANE2.

how many frontends never bothered to handle multi-pass RGB or the -1
document length for handheld scanners? Ever notice how it is hard to
get scanadf to only scan 1 page? Do you know i personally have three
different frontends in hundreds of machines in active use as we speak
that would blow up if they received color data- but no one has ever
tried!

case closed.

allan

-- 
"The truth is an offense, but not a sin"