[sane-devel] SANE frozen in amber ?

[stef]

Le samedi 13 juin 2009 14:55:54 m. allan noah, vous avez écrit :
> On Sat, Jun 13, 2009 at 8:42 AM, stef<stef.dev at free.fr> wrote:
> > Le vendredi 12 juin 2009 19:52:57 m. allan noah, vous avez écrit :
> >> On Fri, Jun 12, 2009 at 12:45 PM, Richard
> >>
> >> Ryniker<ryniker at ryniker.ods.org> wrote:
> >> >> a frontend that asks for new, unsupported features, will simply
> >> >> get an appropriate error code.
> >> >
> >> > Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009)
> >> > alluded
> >> >
> >> > to the problem with this approach when he wrote:
> >> >>bah- then no front-end will use it, since it is not guaranteed to be
> >> >>there.
> >>
> >> <snip>
> >>
> >> > I believe SANE, like many other applications, will find it better to
> >> > change its API in infrequent, discrete steps than to follow a
> >> > "continuous change is permitted" strategy.
> >>
> >> Well, you can't get much more infrequent API changes than SANE :)
> >>
> >> Seriously, we have to bump the major number on the soversion to do any
> >> changes. The only real question is what do we do with all the
> >> unmaintained backends?
> >>
> >> 1: drag them along via modification
> >> 2: leave them behind and make the frontends link against sane1 and sane2
> >> 3: leave them behind and use a sane-compat meta-backend to make them
> >> appear to have the sane2 api
> >> 4: make our API modifications small enough that old backends will be
> >> forward compatible
> >>
> >> Note that all 4 of these options are easier for the programmer if the
> >> API changes are kept small. Are there any other choices?
> >>
> >> allan
> >
> >        Hello,
> >
> >        maybe deciding first on what features we want to bring in would
> > help us to choose. Once we know what to add, it should be easier to plan
> > how to do it.
>
> We already tried that. It is called the sane 2 draft spec, and its
> been sitting on the server for years. IMHO, we should not start
> another round of open-ended dreaming. We must keep in mind what is
> possible, given our limited resources. That is why I started from the
> 'how' instead of 'what' perspective.
>
> allan

	OK,

	but after a quick read, it seems to me that the draft doesn't address user 
notification during warming up, nor the case of sheet fed scanners 
calibration.

Regards,
	Stef