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
