[sane-devel] Sane API

[Ralph Little]

Hi,

On 2020-10-12 2:06 a.m., Olaf Meeuwissen wrote:
> Hi Ralph,
>
> Ralph Little writes:
>
>> I would be interested to participate.
> You're welcome but I'm not sure how we want to go about things.  A lot
> has changed since the bulk of that version 2 draft was written.  From
> what I've seen of the changes (during the conversion from LaTeX to
> Sphinx), they look sensible but I feel there is a lot more that ought
> to be updated for the 2000-twenties.
>
My main motivation is related to my experience in using a few different
devices now and some common usability themes have emerged for me:

1) Often scanners spend a lot of time in calibration and it isn't always
that obvious mechanically or audibly that that is what is going on. It
would be cool if a frontend could emit some kind of status update to
reassure the user that something is actually going on. We don't have
anything in the current spec to support that.

2) Backends have different ideas about what is "advanced" and what is
basic which just looks a bit messy. It would be good to establish some
guidelines on some of the more common options. I'm thinking the x/y, w/h
type options primarily.

3) We talked a bit ago about polling options and it would be good to get
something more formal to deal with this. Just as a reminder, there was a
machine with a "copy count" display indicator that the user could
increment/decrement with buttons next to the display. We can now display
the content of that window but since the value of this is "volatile" and
could be conceptually linked to the scan count in the frontend (e.g.
xsane), there is no way to indicate that the frontend should regularly
poll for the value. Obviously there are frontend issues regarding the
conceptual linkage and there was some concern about idly polling over
the network as a form of DDOS attack, but I think that some thought
might be put into a backend solution to support that capability.

There are probably some other things that are not coming immediately to
mind.

I actually really love the simplicity of the current API and I would
hate to complicate things much if at all. I also appreciate that
whatever happens, the NET protocol has to support it.

As regards the issue of backwards compatibility, that is a serious
concern since many of the machines cannot be easily regression tested.
However, if we could expand the scope of the number of officially
recognised "options", then that might work for much of what I have
listed above.

Cheers,
Ralph