[sane-devel] Fwd: Ricoh SP204SN AIO network scanner

[Alexander Pevzner]

Hi Johannes,

> But in the future this might no longer be true > (at least no longer true in general), cf.> 
https://github.com/apple/cups/issues/5271> and> 
https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003747.html 

This position is actually quite close to mine. It implies a stateful 
middleware between user applications and hardware printers, called 
"printer application", unless, as a special exception, printer natively 
speaks IPP. At this case this "middleware" becomes a part of printer.

In short, my position is following:

1) There must be some common layer between applications and backends. It 
solves the following problems:
   * allows evolving of interface exported by backends without breaking 
applications
   * allows evolving of SANE API, exported to apps without breaking 
compatibility with existing backends and existing apps, using old API
   * outsorces common functions from backend. For example, there is no 
need to reimplement JPEG decoder on every backend that receives JPEG 
from hardware, it's better to be implemented once and for all

2) And this layer should be process, not dynamic library, it solves the 
following problems:
   * faster startup of applications. Popular distros, like Fedora, SuSE, 
Ubuntu etc, tend to enable most of existent SANE backends, and every 
time every scanning-capable application starts, all these backends are 
loaded and initialized just with purpose to detect an absence of 
hardware they support, it takes up to several seconds
   * no need to allow user apps direct access to USB
   * interlocking of scanner access between apps

And it is not so important, will it be a single process for all, or a 
single process for each scanner.

> In the future the user's application may directly communicate
> for each particular printer device with its associated IPP server.
> That IPP server is either running inside native IPP printer hardware
> or it is a so called "Printer Application" which is a software
> wrapper for printing devices that do not support IPP.

Yes. But for scanners we currently don't have a common protocol, like IPP.

> on the other hand in practice any abstraction layer in between
> the user and his hardware can result loss of functionality because
> it reduces the functionality to what the abstraction provides
> and it implements RFC 1925 item 6a:
> "it is always possible to add another level of indirection".

Nice RFC, thank you :-)

Currently with SANE we don't have a reliable programmatic way to tell if 
scanner supports duplex ADF.

> This can lead to inexplicable behaviour for unexperienced users
> in particular in error cases, cf. the section
> "CUPS: The server between user and printer" in
> https://en.opensuse.org/Concepts_printing
> that reads (excerpt):

I still believe it is possible to create good abstractions, though it is 
not simple. IPP is an example of good abstraction for printer.

Fortunately, IPP-scan specification exist, and it provides a good 
abstraction for scanner.

-- 

	Wishes, Alexander Pevzner (pzz at apevzner.com)