[sane-devel] Interactive use of scanner buttons

[Paul Wolneykien]

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