[sane-devel] Additional frame types in Sane 1

[René Rebe]

On Tuesday 29 May 2007 18:17:24 you wrote:
> Am Dienstag, den 29.05.2007, 17:34 +0200 schrieb René Rebe:
> > On Monday 28 May 2007 23:14:22 you wrote:
> > > Am Montag, den 28.05.2007, 18:35 +0200 schrieb René Rebe:
> > > 
> > > > 
> > > > Sane already has so many options that are unsupported by
> > > > most frontends, yet another frametype will not matter much
> > > > at all.
> > > 
> > > Can you give one good example?
> > 
> > All the option names differ from backend to backend already, making
> > live for a frontend unnecessarily hard.
> 
> And what options are unsupported by frontends?

I already mentioned a few, gamma tables can be abritary, undefined
scan lengh is commonly unsupported, many backends have individual
source names, etc. etc. I already menioned more in the thread.

Aside when you find 16bit and more insane I bet the hell break loose
if a backend yields 10 or 12 bit as depth (as commonly returned by
some scanners, but up-scaled to 16bit to make the frontends happy
today.

> > > > If I feel like setting a bitdepth of 32 or 64 bits all frontends
> > > > I saw so far will not handle this as well.
> > > 
> > > This is physically no-sense. Already real 16 bits/sample are only
> > > possible with very low temperature (e.g. fluid nitrogen cooling)
> > > and I have never seen such a scanner.
> > 
> > Still it is allowed in current SANE and not all frontends will deal
> > with it gracefully.
> 
> But it still makes no sense and I don`t want to waste my time to discuss
> thinks that don`t make sense. So please let`s stop to discuss about
> that.

This was just an example. And when some comapny in Japan thinks
24bit per channel is good (tm) and returns it in a backend you have
to deal with that, now.

> > > > > Finish the SANE2 standard. That solves all problems.
> > > > 
> > > > I stopped listening to the SANE 2 bla bla like 5 years ago when
> > > > it became clear to me that the people talking about just want to
> > > > talk and not code.
> > > 
> > > But this is no reason to make SANE-1 unusable by creating incompatible
> > > sane1 versions.
> > > 
> > > When you think sane2 takes too long then make the sane2 proposal to a
> > > sane3 proposal and create a reduced sane2 proposal. But do not make
> > > sane1 corrupt.
> > 
> > Adding new frametypes does not corrupt anything. Securely and
> > sanely written frontends will just say "unsupported frame", and the
> > user can still update to a new frontend that supports jpeg frames.
> > 
> > Also this will continue to just work, as the backends can easily default
> > to the known RGB frames, until the user hits the JPEG UI element.
> > 
> > Btw. We are already implementing this anyway, as companies
> > ask for this. It is just a question to get this into vanilla SANE for
> > all and starting the overdue evolution of SANE, or having some
> > "we use the GPL SANE and here are our enhancements to
> > download".

So what about this arguemnts, nothing?

Apparently for most people SANE 1 is good and enough. As well
as in production use. As we saw over the last years interest
in a start from scratch is rare. Adding some new option frame
types only used in some new backends, where the hack is the
the problem?

Probably you only have interst in your home desktop scanner,
but the professional IT companies using SANE in production,
and I happen to work for one from time to time, only care about
a smooth update path with features ready in weeks, not years.
How should open solutions be competive when we have to
wait for some from sratch rewrite that is beeing talked about
for half a decade, now?

And for my private IR scanner, I can live with my private
backend patch and my own frontend infinitely. But whether
that is progress for all - I have my doubts.

Yours,

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name