On Fri, Dec 3, 2021 at 11:39 AM Paul Wolneykien <mano...@altlinux.org> wrote: > > В 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). >
right, the poller acts as a pass-thru, acts as a front-end when talking to the backend, and acts as a backend when talking to a front-end. We don't have exclusive access problems because the applications make a chain. > Emit events to be handled (how?) by the frontends? Doesn't this > really would make things harder for frontends? No, we could use your proposed mechanism, but we don't have to change backends to support it. > > 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. > I understand, but many backends are unmaintained, and we have a history of front-end authors complaining because of inconsistencies in our backends. As a front-end author, I would not add support for something that only one backend does, and as a backend author, i would not implement a feature that no front-ends support. We can close that gap, and speed adoption of features by using a layered stack of software. allan -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"