[cups.general] Keep printer device info

[Till Kamppeter]

Johannes Meixner wrote:
> 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.

Perhaps HAL needs to be enhanced to serve better for printers. HAL is a 
daemon which observes whether hardware components are connected or 
disconnected and which model they are. On USB it works perfectly. On 
parallel it could observe via the ppdev kernel module whether parallel 
devices are plugged and unplugged and poll their device IDs whenever a 
device is plugged/turned on and check whether the device ID has changed 
and in the case of a change triggering the Plug'n'Print/auto queue 
setup/modification. HAL could even observe which models network devices 
which the system is using (like printer IPs for which there is a print 
queue) are and do a certain action when the model changes. Polling an IP 
for the model name is quick and simple and can be done regularly every 
few seconds. HAL could also be expanded to report Bluetooth devices and 
which model they are.

Problem is still that the tool which gets triggered by HAL must know 
about the backends, their URI structure, which model is the existing 
queue for, which backend is the recommended one if there is more than 
one suitable backend for a printer. system-config-printer only knows to 
do the right thing because it knows about HPLIP.

    Till