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 ([email protected])
