Re: Passing all scanner usage through local saned

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