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. 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@xxxxxxxxxx > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- > John (J5) Palmieri > Associate Software Engineer > Desktop Group > Red Hat, Inc. > Blog: http://martianrock.com > -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com
