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