[sane-devel] Sane Release 1.1.0 ?

[stef]

Le Tuesday 04 November 2008 11:57:15 Julien BLACHE, vous avez écrit :
> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>
> Hi,
>
> > I have a frontend that calls sane_cancel() and throws an exception
> > (and no plans to fix that any time real soon).
>
> The problem with the "warming up" thing is that it is not an error,
> it's a /transient/ *status* that clears itself up with time. So it's
> wrong for an operation to FAIL because of this.
>
> It's the kind of thing that should not be part of SANE_Status (bad
> naming for that, btw, as we see), but should be treated on its own.
>
> We should add a sane_status() call to the API to handle this kind of
> things, so the call flow becomes:
>
> sane_start()
> sane_status()
>  -> warming up: tell the user the scanner is not ready, poll
>     sane_status() until it's ready (but don't busy loop)
>  -> OK: go ahead
> sane_read()
>
> And the better part is, we can make it an optional call and keep the
> current behaviour for SANE 1.0 frontends, effectively enabling a
> backward-compatible SANE 1.1 evolution of the standard.
>
> Later we can make it mandatory in the call flow for SANE 2.0 - then
> sane_read() can bomb out in SANE 2.0 with a "sorry, not ready" if the
> scanner is not ready for whatever reason and the caller did not bother
> to check beforehand (or did and things changed). sane_status() then
> tells you what's up.
>
> Other status returned by sane_status() could be things like: stand by,
> lamp off, lamp on, ... the status could be a bitfield. sane_status()
> could be called at any time between sane_open() and sane_close()
> without ill effects.
>
>
> Again, the whole problem with "warming up" is that it makes no sense
> to have an operation fail because of that; it's wrong wrong wrong, no
> matter how you put it it's still wrong wrong wrong.
>
> A "paper jammed" error is a permanent error condition until the user
> clears it up. There's no point in having the frontend wait for the
> error to clear in this case, because it'll take time and the scanner
> will probably be switched off for that and/or need a reinit
> anyway. Bailing out is the right thing to do here.
>
> I hope this clears things up, and I'd very much like to see that
> implemented that way. It makes much more sense, it's much more useful
> and extensible IMHO.
>
> JB.
>
> --
> Julien BLACHE                                   <http://www.jblache.org>
> <jb at jblache.org>                                  GPG KeyID 0xF5D65169

	Hello,

	I agree with the design you are explaining. But 	the trouble with such 
approach is that adding new function to the API  had been rejected so that 
many unmaintained (or untestable due to lack of hardware) backends can be 
left untouched. Also there haven't been a new SANE standards for years (SANE 
2 last draft will be 6 years old in December) , and presumably, there will be 
never. Adding one more status is then the only way to provide user a feeback 
when the scanner is doing nothing (from user's point of view) during 30s. 
	For me this 'warming thing' isn't a pet feature, it is a clear sign of the 
importance we give to the people using our backends. 

Regards,
	Stef