[sane-devel] Interactive use of scanner buttons

[m. allan noah]

On Fri, Dec 3, 2021 at 11:39 AM Paul Wolneykien <manowar at altlinux.org>
wrote:
>
> В Fri, 3 Dec 2021 11:08:23 -0500
> "m. allan noah" <kitno455 at gmail.com> пишет:
>
> > On Fri, Dec 3, 2021 at 9:33 AM Paul Wolneykien <manowar at altlinux.org>
> > wrote:
> >
> > > В Fri, 3 Dec 2021 09:02:43 -0500
> > > "m. allan noah" <kitno455 at 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20211203/1947247f/attachment.htm>