[sane-devel] SANE2 proposal

[Henning Meier-Geinitz]

Hi,

On Sun, Apr 14, 2002 at 10:45:21PM +0200, Oliver Rauch wrote:
> Henning Meier-Geinitz wrote:
> 
> > Some questions and comments that came to my mind while reading the
> > standard the first time (so I may have missed something):
> > 
> > * 3.2 Image data format and 3.2.1 Image transmission:
> >   The radical change in frame types and frame transmission should be
> >   mentioned earlier in the text.
> 
> Suggestions are welcome.

Ok. I append a LaTeX code for a revised chapter "Image data format". I
mostly moved paragraphs around. I removed the exact descriptions for
the old frame types. Added references to sane_get_parameters. Added
definition of the order of bits in 1-bit modes.

What do you think about it?

> >   We don't know if all the information
> >   about 1, 8, 16 bits per sample are true for some MIME format, do we?
> 
> May be correct. Possibly the value depth makes no sense in MIME format.

I moved this part to SANE_FRAME_RAW.

> >   I'm not sure if we should even mention the old SANE1 frame types.
> >   If someone really wants to use them, he should looak at the SANE1
> >   standard. Or is tehre a special reason for this?
> 
> Once is to tell why values 5 and 6 are used for SANE2 frames,
> onther thing is the idea that a frontend may decide to support
> SANE1 and SANE2 backends.

That's ok. But I don't think we should describe all the old data
structures in detail in SANE 2. The frontend implementor has to read
the old standard anyway (e.g. for the changed sane_open() call).

> It also would be possible to start from 0 and remove the SANE1
> frame types. But this way it would be harder to write a
> SANE1+SANE2 frontend.
> This is one of the points that have to be discussed. May be
> it makes more sense to remove all SANE1 things.

Mention that the types were used by version 1 and add a "don't use
flag". Not more. 

> > 
> >   Add a reference to the chapter about sane_get_parameters fort the exact
> >   meaning of formatdesc.
> 
> There is a describing point formatdesc in sane_get_parameters. What
> do you think about?

That's ok. I just wanted a link to that desription (\ref{some_section}).

> > * SANE_Device.email_backend_author: I'm not sure, if this really
> >   belongs into the structure (and not into the man page and HTML page).
> >   If it's in the code, I would prefer to also have the name of the
> >   author in this entry. This makes it easier to find him when the
> >   email address doesn't exist any longer.
> 
> The email address should look like this:
> 
> Oliver Rauch <Oliver.Rauch at XSane.org>

Ok, better explicitely talk about the name.

> it makes sense to put the email address into the backend because
> if someone uses a backend via network he may not have the manpage
> of the backend.

Ok. Maybe also a URL to the backend homepage?

> > * SANE_Device.device_location: I don't understand this one. Which
> >   location? My device is on the table 1.5m to the right of me :-)
> >   Do you mean the backend? A URL to the vendor? Or a path name?
> >   And why should it be read from the config file (the backend doesn't
> >   even need one and I'm not sure if we should mention this).
> 
> No, I think about a real physical location.
> Imagine you are at work or in the university and 200 computers have
> access to a scanner via network, then it is necessary that a user
> can find out where he finds the scanner, so the entry could look like
> this:
>
> building 93, 2nd plane, room 2113

Ah, ok. Then my first guess wasn't that wrong. Maybe just add your
example to the descriptions, that makes it pretty clear.

> > * SANE_Device.backend_capability_flags: Can you give an example for
> >   such a flag and what the frontend should do with it?
> 
> This is planned for future extensions.
> Let?s say we add a new feature that is not defined in the sane-2.0.0
> standard (e.g. audio support for a camera) then it is necessary that
> the backend can tell te frontend if special features are supported or
> not.

But the features must be supported by some addition function or frame
type in this case, needn't it?

> > * 4.2.10 InternationAlization (missing "a").
> >   Be clear. "Should" is should. There is no "preferrable" necessary.
> >   Maybe we should cite the RFCs' meaning of "MUST" and "SHOULD"
> >   somewhere in the standard?
> 
> We can write "must" but I do not want to force this here, it also does
> work when the backend is written in chineese and we have a chineese
> to english translation

Ok, then just use "should". I didn't like the "preferrable".

> > As an addition, we should make clear what can be changed in a
> > SANE_Option_Descriptor and when. Currently it must only be "vaild" and
> > the address stay the same. E.g. is the backend allowed to change the
> > type of option? Or only capabilities?
> 
> I think it is allowed to change all in sane_control_option when
> SANE_INFO_RELOAD_OPTIONS is set - or am I wrong?

Be carefull. You can change the value and (at least I think so)
SANE_CAP_INACTIVE. You don't know if SANE_INFO_RELOAD_OPTIONS means
that the options are reloaded immediately. info can even be 0.
Even when sane_get_option_descriptor is actually called, it's
currently not allowed to change the returned address until sane_close().
The net backend had this bug until recently.