kopia lustrzana https://gitlab.com/sane-project/website
194 wiersze
7.0 KiB
HTML
194 wiersze
7.0 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>sane-devel: Re: snapscan</TITLE>
|
|
<META NAME="Author" CONTENT="Christian Nassau (nassau@math.uni-frankfurt.de)">
|
|
<META NAME="Subject" CONTENT="Re: snapscan">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: snapscan</H1>
|
|
<!-- received="Mon Jan 15 04:21:57 2001" -->
|
|
<!-- isoreceived="20010115122157" -->
|
|
<!-- sent="Mon, 15 Jan 2001 13:20:34 +0100" -->
|
|
<!-- isosent="20010115122034" -->
|
|
<!-- name="Christian Nassau" -->
|
|
<!-- email="nassau@math.uni-frankfurt.de" -->
|
|
<!-- subject="Re: snapscan" -->
|
|
<!-- id="200101151220.NAA13986@newton.math.uni-frankfurt.de" -->
|
|
<!-- inreplyto="20010110201704.A646@vortex.swb.de" -->
|
|
<STRONG>From:</STRONG> Christian Nassau (<A HREF="mailto:nassau@math.uni-frankfurt.de?Subject=Re:%20snapscan&In-Reply-To=<200101151220.NAA13986@newton.math.uni-frankfurt.de>"><EM>nassau@math.uni-frankfurt.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Mon Jan 15 2001 - 04:20:34 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0148.html">Mark Stewart: "Re: Umax 600s/Adaptec 2906 trouble"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0146.html">Christian Nassau: "Re: SANE standard / get_select_fd / sane_read"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0116.html">Henning Meier-Geinitz: "Re: snapscan"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0149.html">Henning Meier-Geinitz: "Re: snapscan"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0149.html">Henning Meier-Geinitz: "Re: snapscan"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#147">[ date ]</A>
|
|
<A HREF="index.html#147">[ thread ]</A>
|
|
<A HREF="subject.html#147">[ subject ]</A>
|
|
<A HREF="author.html#147">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Hello Henning,
|
|
<BR>
|
|
<P>thanks for your message. But of course I still disagree. ;-)
|
|
<BR>
|
|
<P>You wrote
|
|
<BR>
|
|
|
|
<BR>
|
|
<EM>> The standard defines the meaning of blocking/non-blocking mode in
|
|
</EM><BR>
|
|
<EM>> chapter 4.3.10 (sane_read). Blocking/non-blocking describes the
|
|
</EM><BR>
|
|
<EM>> behaviour of sane_read in the case that no data is available.
|
|
</EM><BR>
|
|
<P>and that brings us to the heart of the matter/problem: The meaning
|
|
<BR>
|
|
of "having data avilable" is not made precise in the standard.
|
|
<BR>
|
|
This notion cannot (and should not) refer to any "physical" entity,
|
|
<BR>
|
|
like an internal buffer in the backend (may not exist), an
|
|
<BR>
|
|
internal buffer in the scanner (may not exist neither), and so on.
|
|
<BR>
|
|
<P>The standard comes close to actualy define the meaning of "available"
|
|
<BR>
|
|
in the following line (taken from the get_select_fd specification):
|
|
<BR>
|
|
<P> ...image data is available, (i.e., when a call to sane_read() will
|
|
<BR>
|
|
return at least one byte of data).
|
|
<BR>
|
|
<P>If we read "i.e." as "equal by definition" we arrive at the
|
|
<BR>
|
|
tautological definition of available: a backend had data available
|
|
<BR>
|
|
iff a call to sane_read transferred at least one byte.
|
|
<BR>
|
|
<P>But actually I don't want to turn this into a lawyer's kind of
|
|
<BR>
|
|
discussion, so let me state my case more plainly and bluntly,
|
|
<BR>
|
|
like this:
|
|
<BR>
|
|
<P>THE SPECIFICATION of sane_read HAS TO BE CHANGED:
|
|
<BR>
|
|
<P> In blocking mode a backend should be allowed to transfer
|
|
<BR>
|
|
zero bytes and return SANE_STATUS_GOOD (i.e. same behaviour
|
|
<BR>
|
|
as currently admitted in nonblocking mode)
|
|
<BR>
|
|
<P>To prove this, I'll show three things:
|
|
<BR>
|
|
<P> A) desireable behaviour made possible by this modification
|
|
<BR>
|
|
B) a (potential) real life example
|
|
<BR>
|
|
C) a remark on the compatibility with existing frontends
|
|
<BR>
|
|
<P>(We always deal with blocking mode in the following.)
|
|
<BR>
|
|
<P>A) A backend might know that data will not arrive in the immediate
|
|
<BR>
|
|
future. If there is nothing useful to be done, the backend
|
|
<BR>
|
|
should be allowed to give control back to the frontend, for
|
|
<BR>
|
|
example to allow user interaction.
|
|
<BR>
|
|
<P> (Currently, it is forced to explicitly wait (= waste time) in this
|
|
<BR>
|
|
case.)
|
|
<BR>
|
|
<P>B) Assume the backend is reading image data from a remote host over
|
|
<BR>
|
|
an TCP/IP connection. (For example, we could be scanning the
|
|
<BR>
|
|
Mona Lisa through the Louvre's internet server.) In this case
|
|
<BR>
|
|
there is no access to the scanner that could --- in any substantial
|
|
<BR>
|
|
way --- be called blocking. So for this device non-blocking mode
|
|
<BR>
|
|
is the only one that is "naturally" supported, and blocking mode
|
|
<BR>
|
|
would have to faked (= simulated), by deliberately wasting time.
|
|
<BR>
|
|
<P>C) If a frontend depends on sane_read's old (= current) behaviour
|
|
<BR>
|
|
it can simulate it like this:
|
|
<BR>
|
|
<P> do {
|
|
<BR>
|
|
call sane_read
|
|
<BR>
|
|
} while (no error && no bytes transferred)
|
|
<BR>
|
|
<P><P>So I think this actually proves that the standard should be changed.
|
|
<BR>
|
|
<P>Of course I don't know if I'm right, and actually hope for counter
|
|
<BR>
|
|
opinions. However, any counter argument should do one of the
|
|
<BR>
|
|
following:
|
|
<BR>
|
|
<P>Either
|
|
<BR>
|
|
|
|
<BR>
|
|
Show that I'm wrong about points A, B, or C.
|
|
<BR>
|
|
<P>or
|
|
<BR>
|
|
<P> Point out undesirable behaviour permitted by the new specification.
|
|
<BR>
|
|
(But make sure this behaviour is not currently allowed!)
|
|
<BR>
|
|
<P>Christian
|
|
<BR>
|
|
<P><PRE>
|
|
--
|
|
Source code, list archive, and docs: <A HREF="http://www.mostang.com/sane/">http://www.mostang.com/sane/</A>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <A HREF="mailto:majordomo@mostang.com?Subject=Re:%20snapscan&In-Reply-To=<200101151220.NAA13986@newton.math.uni-frankfurt.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0148.html">Mark Stewart: "Re: Umax 600s/Adaptec 2906 trouble"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0146.html">Christian Nassau: "Re: SANE standard / get_select_fd / sane_read"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0116.html">Henning Meier-Geinitz: "Re: snapscan"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0149.html">Henning Meier-Geinitz: "Re: snapscan"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0149.html">Henning Meier-Geinitz: "Re: snapscan"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#147">[ date ]</A>
|
|
<A HREF="index.html#147">[ thread ]</A>
|
|
<A HREF="subject.html#147">[ subject ]</A>
|
|
<A HREF="author.html#147">[ author ]</A>
|
|
</UL>
|
|
<!-- trailer="footer" -->
|
|
<HR NOSHADE>
|
|
<P>
|
|
<SMALL>
|
|
<EM>
|
|
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
|
: <EM>Mon Jan 15 2001 - 04:22:16 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|