[sane-devel] Sane API

[Alexander Pevzner]

Hi Ralph,

On 10/12/20 9:00 PM, Ralph Little wrote:
> 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.

It would be nice to have a generic mechanism for unsolicited 
notifications from backend. Use cases: device status changes, as you've 
mentioned, push scan events, PnP (device discovery) events, button press 
notifications.

> 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.

This is better to define a standard set of options, with the same name 
and interpretation for all backends. It will let frontends to decide by 
themselves, which oprions are advanced from their own perspective.

It will also help a lot to write non-interactive frontends.

> 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.

If polling of some counter is required by underlying network protocol, 
backend may limit an actual frequency of network requests, and if 
frontend polls too often, just return cached value, which is updated 
with reasonably frequency.


> 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.

I think, we have no other choice that to let SANE 1.0 and SANE 2.0 to 
coexist, providing a necessary translation layer.

There are a lot of SANE 1.0 backends, that honestly speaking, will never 
be updated, and some SANE 1.0 frontends (fortunately, not so much), that 
unlikely to be immediately updated to use the new API.

-- 

	Wishes, Alexander Pevzner (pzz at apevzner.com)