Hello Henning,
thanks for your message. But of course I still disagree. ;-)
You wrote
> The standard defines the meaning of blocking/non-blocking mode in
> chapter 4.3.10 (sane_read). Blocking/non-blocking describes the
> behaviour of sane_read in the case that no data is available.
and that brings us to the heart of the matter/problem: The meaning
of "having data avilable" is not made precise in the standard.
This notion cannot (and should not) refer to any "physical" entity,
like an internal buffer in the backend (may not exist), an
internal buffer in the scanner (may not exist neither), and so on.
The standard comes close to actualy define the meaning of "available"
in the following line (taken from the get_select_fd specification):
...image data is available, (i.e., when a call to sane_read() will
return at least one byte of data).
If we read "i.e." as "equal by definition" we arrive at the
tautological definition of available: a backend had data available
iff a call to sane_read transferred at least one byte.
But actually I don't want to turn this into a lawyer's kind of
discussion, so let me state my case more plainly and bluntly,
like this:
THE SPECIFICATION of sane_read HAS TO BE CHANGED:
In blocking mode a backend should be allowed to transfer
zero bytes and return SANE_STATUS_GOOD (i.e. same behaviour
as currently admitted in nonblocking mode)
To prove this, I'll show three things:
A) desireable behaviour made possible by this modification
B) a (potential) real life example
C) a remark on the compatibility with existing frontends
(We always deal with blocking mode in the following.)
A) A backend might know that data will not arrive in the immediate
future. If there is nothing useful to be done, the backend
should be allowed to give control back to the frontend, for
example to allow user interaction.
(Currently, it is forced to explicitly wait (= waste time) in this
case.)
B) Assume the backend is reading image data from a remote host over
an TCP/IP connection. (For example, we could be scanning the
Mona Lisa through the Louvre's internet server.) In this case
there is no access to the scanner that could --- in any substantial
way --- be called blocking. So for this device non-blocking mode
is the only one that is "naturally" supported, and blocking mode
would have to faked (= simulated), by deliberately wasting time.
C) If a frontend depends on sane_read's old (= current) behaviour
it can simulate it like this:
do {
call sane_read
} while (no error && no bytes transferred)
So I think this actually proves that the standard should be changed.
Of course I don't know if I'm right, and actually hope for counter
opinions. However, any counter argument should do one of the
following:
Either
Show that I'm wrong about points A, B, or C.
or
Point out undesirable behaviour permitted by the new specification.
(But make sure this behaviour is not currently allowed!)
Christian
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 04:22:16 PST