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

[Johannes Meixner]

Hello,

On Mar 2 22:37 Alexander Pevzner wrote (excerpt):
>
> Currently, there is no such a piece of software, as "SANE".
> There are SANE backends and SANE frontends,
> but there is no "SANE" in between.
>
> What I propose, is to insert a process between frontends and backends,
> without need to break API compatibility. It will simplify many things.
> Printing architecture has a similar design: applications don't
> communicate with printers directly, but rather communicate with
> print server, which drives hardware.

Yes, the current printing architecture (at lesst usually on Unix/Linux)
has the design to have the CUPS daemon in between the user's application
and his printer hardware where in particular that daemon runs the
printer driver software as one part of the filtering programs,
cf. the section "The Filter (includes the Driver)" in
https://en.opensuse.org/SDB:CUPS_in_a_Nutshell

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

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.

In general a hardware abstraction layer is "the right thing"
in particular from a theoretical design point of view
BUT
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".

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):
-----------------------------------------------------------------
Strictly speaking from the computer's internal point of view
it usually doesn't know about the actual printer devices
but only about print queues.
What CUPS and application programs call "printers" are usually
not the actual printer devices but only their associated print
queues.
This sketchy usage of the word "printer" for the computer's
internal representation can lead to confusion when it is
not clear for the user what it actually means when CUPS
or application programs show that everything is o.k. with
the "printer".
Usually this means that the state of the print queue is o.k.
(e.g. "ready") but the state of actual printer device could
be different at the same time (e.g. "out of paper").
-----------------------------------------------------------------

So it makes sense to avoid generic hardware abstraction layers
and let the user's program directly communicate with the hardware.

For example for printing let the user's program directly
communicate via IPP with native IPP printer hardware
or as band-aid workaround via IPP with a Printer Application.

In this case it belongs to the native IPP printer hardware
how it deals with very many simultaneous IPP connections
or many (possibly huge) subsequent IPP print jobs
and things like that.


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer