[cups.general] Keep printer device info

[Johannes Meixner]

Hello,

this is a proposal for a CUPS enhancement and I like to discuss it
on the mailing list before I enter it as STR.

  The printing system should keep printer device info.

I suggest to store and keep printer device info in a new file
/etc/cups/devices.known
with printer device entries which point to the queue entries
in /etc/cups/printers.conf which belong to the device (if such
queue entries exist).

Furthermore I suggest to keep any printer device info
which was autodetected at any time in the past in this file.
To distinguish possibly outdated entries from up-to-date entries,
I suggest to maintain a time-stamp for each device entry
when the device was autodetected and a general time-stamp
when the cupsd did run all its backends in device discovery mode.
An entry is up-to-date if the general time-stamp is the same
as the time-stamp for the individual device entry.
Why keep possibly outdated entries?
Think about a laptop user who has different printers in
different environments and queues for all those printers.
If device entries would be removed when the device cannot
be autodetected currently, the printer device info for
several of his queues would get lost.
I think it is up to a printer management tool to display
really possibly outdated entries (e.g. those which are
currently not autodetected and for which no queue exists)
to the user and let him decide what to do.


Details and background information:

during the OpenPrinting Summit in Montreal I found out that
"there is no printer in the printing system".

What I mean is that there is no software representation
of the real piece of hardware in the printing system.

Actually queues and printers are very different things.

A printer is a piece of hardware.

A queue is basically a named output channel
which (hopefully) results correct output on a printer.

One can have printers but no queues.

One can have queues but no printers.

One can have anything else in between.

The kernel or whatever low-level system has a software representation
of a printer, for example the USB device IDs which "lsusb" shows
or what a kernel module gets during autoprobing of the parallel port
or what an SNMP tool may detect in the network and so on, basically
what the CUPS backends show when they run in device discovery mode.

But once a queue was set up, the printing system does not remember
the software representation of the real piece of hardware for
which the queue was set up.

All what is done is that from the software representation of
the real piece of hardware a more or less abstract description
is derived (the so called DeviceURI) which describes basically
only how the the piece of hardware is connected to the computer
so that the printing system (the CUPS backend) can send its data
out of the computer.

But (almost) nothing in the printing system really knows what
there is really at the end of the "named output channel".

The DeviceURI is for example something like:
usb://ACME/FunPrinter?serial=A1B2C3
prallel:/dev/lp0
socket://192.168.101.202:9100

Only the usb backend DeviceURI contains a software representation
of the real piece of hardware but even for USB printers one
cannot rely on that there is always such a representation
of the real piece of hardware because a thrid-party backend
can have whatever DeviceURI it likes.
For example a backend from the manufacturer "ACME" which
provides more functionality than the generic CUPS usb backend
(e.g. "printer maintenance" functions - see above) could have
acme://usb/A1B2C3
to describe the same connection as the CUPS usb backend above
(e.g. because the acme backend implicitely knows that only
USB printers with manufacturer "ACME" are of interest for it
and that it can derive the model from the serial number).

Furthermore several backends for the same kind of connection
(here usb and hp for a USB printer) can report the same device
differently, e.g. on my workstation for a HP LaserJet 1220:
usb://HP/LaserJet%201220
hp:/usb/HP_LaserJet_1220?serial=00XXXXXXXXXX


Some examples of bad consequences:

What happens if a printer is disconnected from the parallel port
and replaced by a different model?
Nothing happens.
The printing system would not notice that a different piece of
hardware is now at the end of the connection.
The printing systen still sends the same kind of data out of the
computer and in the best case the new piece of hardware doesn't
print anything but in the worst case it prints tons of sheets
with meaningless nonsense characters.
The same bad consequence if a network printer is replaced by a
different model (with same IP).

What could be done if a user likes to find out for which printers
in his environment (in particular think about a bigger networked
environment in a company) there exists already a queue and for
which printers not?
Nothing can be done by software.
It is up to the imagination of the user to check the info strings
of the queues which he might see by luck on his local system
to find out which queue matches to which printer.

Furthermore a reliable printer autoconfig tool cannot exist
because in general it is not possible to find out for an
autodetected printer if there exists already a queue for it.
One can do some "best guess" based on the usb DeviceURI
but there is not only the usb backend for USB printers,
see the usb versus hp example above.

Printer management tools cannot exist.
Queue management tools exist and also special tools for
printer maintenance (like "hp-toolbox") exist
but a generic printer management tool cannot exist.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex