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 > >
