system-config-printer

[John (J5) Palmieri]

Oh, one more thing I forgot:

I would like to see an easy way for the backend to mark and configure a
local queue for sharing. 

On Thu, 2005-02-03 at 15:02 -0500, John (J5) Palmieri wrote:
> Ok,
> 
> 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
> backend.
> 
> * 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
> 		  driver.
> 
> 		- 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
> used.
> 
> [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.
> 

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com