# Re: snapscan

From: Christian Nassau (nassau@math.uni-frankfurt.de)
Date: Mon Jan 15 2001 - 04:20:34 PST

- Next message: Mark Stewart: "Re: Umax 600s/Adaptec 2906 trouble"
  - Previous message: Christian Nassau: "Re: SANE standard / get_select_fd / sane_read"
  - In reply to: Henning Meier-Geinitz: "Re: snapscan"
  - Next in thread: Henning Meier-Geinitz: "Re: snapscan"
  - Reply: Henning Meier-Geinitz: "Re: snapscan"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  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

  - Next message: Mark Stewart: "Re: Umax 600s/Adaptec 2906 trouble"
  - Previous message: Christian Nassau: "Re: SANE standard / get_select_fd / sane_read"
  - In reply to: Henning Meier-Geinitz: "Re: snapscan"
  - Next in thread: Henning Meier-Geinitz: "Re: snapscan"
  - Reply: Henning Meier-Geinitz: "Re: snapscan"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 04:22:16 PST