system-config-printer
John (J5) Palmieri
johnp at redhat.com
Thu Feb 3 20:02:19 UTC 2005
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 at redhat.com
> > 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
More information about the fedora-devel-list
mailing list