[sane-devel] SANE2 standard revisited: Code flow

[Henning Meier-Geinitz]

Hi,

On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
> http://www.meier-geinitz.de/sane/sane2/

Now the code flow:

| 4.4 Code Flow
http://www.meier-geinitz.de/sane/sane2/0.07/doc013.html#s4.4

Just a general comment: This is one of the most important parts of the
SANE standard and it got too little attention from some backend
authors including me. E.g. until recently, I hasn't been sure that
opening multiple devices was explicitely allowed in the standard:

| Once a device has been chosen, it is opened using a call to
| sane_open(). Multiple devices can be open at any given time. A SANE
| backend must not impose artificial constraints on how many devices can
| be open at any given time. 


| An opened device can be setup through the corresponding device handle
| using functions sane_get_option_descriptor() and
| sane_control_option(). While setting up a device, obtaining option
| descriptors and setting and reading of option values can be mixed
| freely. It is typical for a frontend to read out all available options
| at the beginning and then build a dialog (either graphical or a
| command-line oriented option list) that allows to control the
| available options. It should be noted that the number of options is
| fixed for a given handle. However, as options are set, other options
| may become active or inactive. Thus, after setting an option, it may
| be necessary to re-read some or all option descriptors.
[...]

Also their constraint can be changed.

And: How do you know, which options to reread when
SANE_INFO_RELOAD_OPTIONS is returned? So you always must reload all
options (but option 0).

Proposal:

"... However, as options are set, other options may become active or
 inactive or their constraint may change. Thus, after setting
 an option, it may be necessary to re-read the descriptors."

| Image data is collected by repeatedly calling sane_read() until this
| function will return an end-of-file status (SANE_STATUS_EOF). This
| indicates the end of the current frame.

Is this change of wording intended? The old standard says:

| Image data is collected by repeatedly calling sane_read(). Eventually,
| this function will return an end-of-file status (SANE_STATUS_EOF).
| This indicates the end of the current frame. 

I'm not sure but the new versions sound like you must call sane_read()
until EOF while the old version seems to allow to use the select_fd to
detect EOF. So with the new version we need to call sane_read to get
the EOF even if we already know of EOF from the select_fd. Does this
make sense?

The example pseudo code is nice. I would pipe it through indent -gnu
or at least use a sonsitant coding style but that's just cosmetics :-)

Bye,
  Henning