[sane-devel] Interactive use of scanner buttons

[m. allan noah]

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.

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

-- 
"well, I stand up next to a mountain- and I chop it down with the edge of
my hand"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20211203/929f1821/attachment.htm>