[sane-devel] Interactive use of scanner buttons

[Paul Wolneykien]

В Fri, 3 Dec 2021 09:02:43 -0500
"m. allan noah" <kitno455 at gmail.com> пишет:

> Many backends are single threaded currently, so this would be a pretty
> invasive change.

  But that's not a required change, isn't it? If a backend isn't ready
for it, it just should not add SANE_CAP_DYNAMIC to the options.


> Frankly, polling over the network once per second is
> not that much traffic, and certainly easier to implement.
> 
> allan
> 
> On Fri, Dec 3, 2021 at 8:50 AM Paul Wolneykien <manowar at altlinux.org>
> wrote:
> 
> > В Thu, 2 Dec 2021 17:29:13 -0800
> > Ralph Little <skelband at gmail.com> пишет:
> >  
> > > However, regular polling can be
> > > detrimental as a general feature. One commentator suggested that
> > > over a network, this could become an unnecessary bandwidth hog.
> > > In SANE we would want to add polling features in a generic
> > > fashion and we should wary of undesirable side-effects. Flooding
> > > a network just because you are sitting in an idle instance of
> > > xsane is certainly such an example. It is something that we
> > > should discuss carefully before enhancing the standard.  
> >
> >   Yes, polling over the network is a very bad idea. That means, we
> > need something like subscribe+notify interface in SANE. What about
> > the following API upgrade?
> >
> >   A new capability for dynamic options (not only the buttons, but
> > all things that could be changed by the scanner inself):
> >
> >   +  #define SANE_CAP_DYNAMIC
> >
> >   Then a new action for sane_control_option() indicating we want to
> > subscribe to scanner-initiated updates of the given value:
> >
> >   + SANE_ACTION_SUBSCRIBE
> >
> >   Then a function type for a notification handler pointer:
> >
> >   + typedef void (*sane_option_change_callback)(SANE_Int option,
> > void *value);
> >
> >   Having these minor API changes, it's become possible to make a
> > call to sane_control_option() like the following:
> >
> >   sane_control_option(sane_handle, option_number,
> > SANE_ACTION_SUBSCRIBE, my_handler, NULL);
> >
> >   And if the option option_number is marked as SANE_CAP_DYNAMIC in
> > the option descriptor, the backend should setup the given
> > notification handler and invoke it each time the option is updated.
> >   For options not explicitly marked as dynamic it should return
> > SANE_STATUS_UNSUPPORTED. So, no changes are required for the present
> > backends.
> >
> >   How the backend could monitor the option changes? It's up to the
> > backend. But with the present codebase/hardware polling would be
> > used most of the time, I guess. That will be, however, a local-only
> > polling over USB or SCISI interfaces, not a polling over the
> > network as the backend code runs on the server connected to the
> > scanner in the client-server scenario. Of course we also need to
> > implement the proper RPC in order to support callbacks over the
> > network, but that doesn't affect the backends and doesn't require
> > more API changes.
> >
> >   As to a resident polling process inside the backend, we already
> > have sanei_thread_*() functions for that.
> >
> >  
>