В Fri, 3 Dec 2021 11:08:23 -0500 "m. allan noah" <kitno...@gmail.com> пишет:
> On Fri, Dec 3, 2021 at 9:33 AM Paul Wolneykien <mano...@altlinux.org> > wrote: > > > В Fri, 3 Dec 2021 09:02:43 -0500 > > "m. allan noah" <kitno...@gmail.com> пишет: > > > > > 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. > > That makes things hard for front-end developers, because of the > variation between backends. This will negate one of the strengths of > sane (few frontends supporting lots of backends). > > I wonder if there is another approach here- middleware? Similar to how > backends are unaware that they are being used over the network with > saned, perhaps we could have a kind of intermediary poller, which ran > on the machine with the scanner? It could emit events, and not > require all backends which support buttons to be updated? As far as I know, SANE provides exclusive access to the scanner for one client only. So, we can run a poller or a frontend, but not both. That's why I would like to see the polling process running "inside" backend (be launched from the backend as a thread). Emit events to be handled (how?) by the frontends? Doesn't this really would make things harder for frontends? And again: I don't want to require any backend to support notification features. The same for the frontends. All what I propose is the use of two additional constant values, indicating new type of capability and a new type of action --- thanks to the completely abstract sane_get_option_descriptor() and sane_control_option() design.