John (J5) Palmieri johnp at
Thu Feb 3 20:02:19 UTC 2005


Now that I have outlined the current process I would like to make some
suggestions on what I would like to see in terms of a printer
configuration architecture in the future.

* Kill hal_lpadmin - I originally wrote this so I could create queues
using IPP[1] and it worked up to the point that I needed to create an
actual PPD[2] file.  I ended up changing it to just exec printconf.  In
theory all the functionality in here should move to the new printing

* Eventually get rid of cups-config-daemon - We need to keep it for now
since it takes up minimal resources.  cups-config-daemon should become a
liaison for translating dbus messages to the new printconf backend
commands.  Once system service activation is developed we can dump cups-
config-daemon and place all the D-BUS functionality directly into the
printconf backend.   Activation will then be able to start up the
backend which can in turn service D-BUS requests directly.  Resource
usage is less important when activation is in play because the resources
can be returned after printconf services the request (unlike the
situation now where cups-config-daemon need to run all time on the off
chance it will be called upon to configure a printer).

* Enhancements to the backend:
	- Make it more knowledgeable - have it use hal to track printers

	- Make it more intelligent
		- Give it one command to auto-configure a printer.  

		- Have it determine if it has the drivers it needs 
		  and automatically create a queue and name it.  

		- If it can't find the driver have it talk to the
	  	  console session so that it can get the user configured

		- Give it the ability to have queue's renamed and 
		  remember those queue names the next time the printer
		  is plugged in.

		- Give it the ability to accept and install 3rd party
		  PPD files and use that PPD file whenever the printer
		  shows up again (How secure is this? Can PPD files
		  execute code it shouldn't?)

		- Have the ability to lock down specific printers from
		  being auto-configured and also the ability to not
		  allow any printers to be auto-configured.

		- Have the ability to delete queues by name or hal udi

	- Have it talk CUPS' language - CUPS speaks IPP and since it
	  will be hard to get D-BUS patches upstream we should just
	  use IPP to do live configurations of auto-configured
	  printers.  I was successfully doing this in hal_lpadmin
	  sans the PPD files.  This works great because CUPS gets
	  the configuration on the fly so it doesn't have to 
	  refresh its printer list like it does now when we send 
	  the HUP signal.  We will use the D-BUS protocol where
	  authentication is a problem (user session) and translate
	  those D-BUS calls to IPP calls. 

	- Allow an admin to change or add configuration to the foomatic 
	  database just in case things are wrong or nonexistent.  
	  Perhaps add a way to export these changes for attachment 
	  to a bug report.

	- Make sure the system-config tools and the desktop tools play
	  nice with the queues.  (i.e. the two should not step on each
	  others feet. If a printer is already statically added via the
	  admin tool auto-configure should not create a new queue.  Also
	  if the admin tool made changes to an auto-configured queue
	  those changes should be honored the next time the printer is
	  plugged in)

	- Figure out a way to have this all still work in a stateless 
	  environment (read only root)

Ok, that is all I can think of for now.  It is enough to discuss.  Would
like input on what everyone thinks about this and anything they would
add, remove or tweak.

[1] The Internet Printing Protocol (IPP) is a sanctioned Internet
Engineering Task Force (IETF) standard for printing documents over the
web. IPP defines basic handshaking and communication methods, but does
not enforce the format of the print data stream. Typically, a standard
page description language, such as HP PCL or Adobe PostScript, would be

[2] PostScript Printer Description file. A file that contains
information on screen angle, resolution, page size and device-specific
information for a file to be printed on a PostScript device.

On Wed, 2005-02-02 at 16:02 -0500, John (J5) Palmieri wrote:
> Overview on how desktop printer configuration currently works:
> 1. Printer is plugged in
> 2. HAL is notified and calls the printer-update.hal shell script 
>    in /etc/hal/capability.d/
> 3. hal_lpadmin from the hal_cups_utils package is called with the 
>    printer's udi (what HAL uses to identify devices).
> 4. hal_lpadmin checks to see if the device is a printer and if so 
>    gets the make and model of the device from HAL
> 5. A command is constructed to execute printconf's match-driver command
> 6. If a match is found we 
> 	- construct printconf's add-local command to add the printer
> 	- execute printconf-backend --force-rebuild to output the cups 
> 	  configuration files
> 	- send a HUP signal to cups to reload its data
> 7. If a match is not found we
> 	- Ask the console user's session through eggcups if they have a 
> 	  driver match for the make and model in gconf
> 		- if no we then prompt the user to select the closest 
> 		  make and model that matches their printer and is in 
> 		  our foomatic database
> 			- The user selects a make an model which is then
> 			  entered into gconf and a message is sent to 
>                           cups-config-daemon which executes step 6
> 			  with the selected make and model
> 		- if yes we get the make and model returned by gconf
> 		  and go back to step 6
> * On session startup eggcups will loop through the list of printers in
> gconf and configure them if they exist in HAL
> What printconf does (I have limited knowledge of how printconf works so
> can you correct me here Tim?):
> * printconf's match-driver command will return the name of the driver 
>   given a make and model of a printer
> 	- if a driver is found go to step 6 above
> * printconf's add-local command sets up a local print queue in the 
>   sysconfig database using the make and model of the printer.
> * printconf-backend --force-rebuild outputs the queues it finds in
>   the sysconf database into cups config files.
> 	- the make and model are looked up in foomatic
> 	- a PPD file is written out based on the config info 
> 	  in foomatic
> 	- printers.conf is updated with the new queue info
> 	- the queue is created in /var/spool/cups
> * The HUP signal to cups tells it to reload its config files and pick 
>   up the new printers
> That is the basics.  A lot of the desktop configuration can be
> simplified by putting functionality into the backend.  I will post a
> list of features and designs I would like to see go into a rewritten
> system-config-printer soon.
> On Tue, 2005-02-01 at 12:11 +0000, Tim Waugh wrote:
> > The tool we provide for configuring printers needs to change.
> > 
> > The one we have works as designed, but unfortunately the design was
> > that:
> > 
> > * print queue configuration is stored in an XML file
> > 
> > * a front-end interface allows the user to manipulate the XML file
> > 
> > * a back-end program, which runs at spooler start-up time, writes out
> >   spooler-specific configuration based on the XML file
> > 
> > There are several bad consequences of this:
> > 
> > * the XML file format was and is inflexible
> > 
> > * the configuration options are limited to those common to both
> >   spoolers we were shipping at the time the XML format was decided
> > 
> > * it is VERY SLOW: you can't *modify* configuration, only write out
> >   entirely new configurations (i.e. trigger the back-end)
> > 
> > * again, due to the XML format chosen, we are tied to the foomatic
> >   database in such as way that we absolutely require foomatic to know
> >   about the printer before we can configure it.
> > 
> >   Even if you have the manufacturer's PPD file, there is very little
> >   you can do to get your printer working.
> > 
> > * changes made using the CUPS configuration interface
> >   (http://localhost:631/), or any other method external to
> >   system-config-printer, are not reflected in the XML file and so
> >   cannot be modified.
> > 
> > * changes made using system-config-printer cannot be modified using
> >   other tools, since changes will be overwritten.
> > 
> > and so on.
> > 
> > Does anyone have ideas for how system-config-printer should be
> > re-written?
> > 
> > Thanks,
> > Tim.
> > */
> > -- 
> > fedora-devel-list mailing list
> > fedora-devel-list at
> >
> -- 
> John (J5) Palmieri
> Associate Software Engineer
> Desktop Group
> Red Hat, Inc.
> Blog:
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.

More information about the fedora-devel-list mailing list