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