Well, that and if the access to the scanner is locked at the saned level, polling isn't going to tie it up and saned can always return a "We're busy scanning" signal.
On Fri, Dec 3, 2021 at 9:03 AM m. allan noah <kitno...@gmail.com> wrote: > > 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 <mano...@altlinux.org> wrote: >> >> В Thu, 2 Dec 2021 17:29:13 -0800 >> Ralph Little <skelb...@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" -- Kelly "STrRedWolf" Price http://redwolf.ws