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