[sane-devel] Fwd: Ricoh SP204SN AIO network scanner
pzz at apevzner.com
Thu Mar 5 13:53:15 GMT 2020
> But in the future this might no longer be true > (at least no longer true in general), cf.>
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
* 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
* 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
> 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)
More information about the sane-devel