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
