В Fri, 3 Dec 2021 09:02:43 -0500 "m. allan noah" <[email protected]> пишет:
> 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 <[email protected]> > wrote: > > > В Thu, 2 Dec 2021 17:29:13 -0800 > > Ralph Little <[email protected]> пишет: > > > > > 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. > > > > >
