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