Hi Thierry,
On 5/11/24 19:44, [email protected] wrote:
I don't think I understand what you're saying!
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.
We are currently speaking about the following SANE architecture switch.
Intead dlopen-ing libsane-XXX.so backends directly by the client
application, the new architecture proposes the following:
1. There are one (or even multiple) system daemons
2. These daemons dlopen appropriate libsane-XXX.so backend
3. And these daemons expose scanner functionality using some network
protocol and localhost address
4. And user applications don't speak directly with hardware, but using
these daemons as proxy.
It sounds a bit overcompensated, but this architecture has many
advantages over existent one:
1. libsane-XXX.so can be isolated (into snap, flatpack or whatever else)
together with its own instance of scanning daemon. This is important for
distros that prefer to keep all parts in separate containers
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).
3. Only this scanning daemon needs direct access to USB. Users will not
longer need direct access to USB devices.
4. Access control can be implemented very straightforward and cleanly,
in the scanning daemon in pure software, not near hardware.
What we are actually discussing now, is what network protocol to use for
communication with that daemon.
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).
Please note, we are speaking about communication protocol that will be
used to communicate with software daemon, not with the printer hardware.
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.
--
Wishes, Alexander Pevzner ([email protected])
