Re: Probable Bugs & Suggestions

David Mosberger-Tang (David.Mosberger@acm.org)
Wed, 14 Jan 1998 09:51:07 -0800

>>>>> On Tue, 13 Jan 1998 09:15:50 +0100 (MET), R.E.Wolff@BitWizard.nl (Rogier Wolff) said:

Rogier> What is wrong with the backend returning "busy", and a
Rogier> frontend then having to conclude "oops, can't seem to do
Rogier> that right now"?

Rogier> + No added options
Rogier> + Allows for selective "locking".
Rogier> + Minimal intrusion in installed base.
Rogier> - frontends must perform a scan to be able to gray out
Rogier> invalid options.

I don't particular like this solution. A reasonably technical
argument against it is that it would be slow to gray out options when
talking to a scanner over a high-latency/high-bandwidth link. This is
because for each option a dummy set-option call would have to be
performed, which costs a network roundtrip.

Also, it is wrong to return SANE_STATUS_DEVICE_BUSY as a result of an
attempt to change an option. This status value indicates that the
device is busy and retrying the operation after a while may fix the
problem. This is not the case for options that should remain fixed
during a scan (because retrying the operation will not succeed, unless
the frontend first finished the scan operation).

Upon reflection, I really prefer the second solution I suggested: we
add a SANE_CAP_ACTIVE_WHILE_SCANNING bit to the option descriptor
capabilities. That way, backends can indicate which options are to
remain controllable (not grayed out) while a scan is in progress. I
think this solution has all the advantages without any drawbacks.
It's also simple to realize: only xscanimage and the qcam backend
would have need some changes (the backend changes are trivial).

--david

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com