Re: Passing all scanner usage through local saned

I would also add that, as an application developer, I would much appreciate
something like this being available in general (not just on NixOS). When I
distribute as a Flatpak/Snap, my application can't access all SANE scanners
on the system, only those whose drivers I've specifically bundled in the
Flatpak. A level of network indirection would solve this.

To answer the question of whether the saned protocol is stable, it is part
of the SANE Standard <https://sane-project.gitlab.io/standard/1.06/net.html>
which hasn't been updated since 2008, so presumably it is very stable.

As far as which protocol to use - my 2c is that saned is an existing
protocol with the needed capabilities (perhaps with some minor tweaks).
Implementing a new standard seems like overkill, and attempting to map
every possible SANE parameter to eSCL seems unnecessary.

On Sat, May 11, 2024 at 10:39 AM ThierryFR via sane-devel <
[email protected]> wrote:

> Le 2024-05-11 17:16, Alexander Pevzner a écrit :
> >> The eSCL and WSD devices provide their capabilities, so I don't see
> >> how an "IPP Scan" overlay would be better (the implementation why
> >> not).
> >> I prefer the PIXMA or EPSONSCAN2 backends, which expose many more
> >> properties than eSCL or WSD.
> >
> > Let me try to explain these things a little bit.
> Thanks Alexander, that makes it clearer!
>
> > 2. The daemon may initialize early, so when user application wants to
> > scan, everything is ready (currently, if there are many backends
> > enabled, initialization may take seconds).
>  From my point of view, a scanner configuration module is missing, so as
> not to waste time on initialization.
> Initialization should just be a readout of configured devices.
>
> > The choice is between SANE's native protocol (used by saned and
> > sane-net backend) and standard-compliant scanning protocol (here we
> > have eSCL, WSD, TWAIN Direct and IPP-scan).
> Once a configuration exists, sane-net is operational.
>
>
> > So it is not actually correct to say that eSCL is limited in comparison
> > to the PIXMA protocol.
> >
> > Cannon implementation of eSCL may be limited (and this is Canon's
> > decision to promote their proprietary protocol by limiting their
> > implementation of the standard eSCL), but these limitations are not
> > part of the eSCL specification by itself, and other hardware exposes
> > all its functionality to both proprietary protocol and to eSCL.
> You're right, the problem isn't the protocol but the manufacturers,
> because this isn't unique to Canon.
>
> Thierry
>
>