Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Mike Sweet <mike@easysw.com>]

Robert L Krawitz wrote:
> ...
> That sounds like a good architecture anyway.  I don't see why the
> filter couldn't also act as an "option server" or some such, though.

You'd be forcing every driver to handle multiple requests at the
same time, or serializing requests which would invoke a serious
performance hit.  Also, keep in mind that serving a static file/
data store involves MUCH less CPU/IO than processing each query
individually.  Any solution we come up with has to scale to
thousands of printers and users.

>    Ideally we should be able to provide a GIMP-print API for
>    retrieving the driver constraints and/or put all of the driver-
>    specific data in the printers.xml file so that the driver and PPD
>    files are data driven and not hardcoded.  This would also make it
>    possible for programmatic PPD file generation - CUPS would ask
>    GIMP-print for a list of the drivers it supports along with
>    "virtual" PPD filenames, and then CUPS can have GIMP-print write
>    the PPD file in /etc/cups/ppd as requested by the administrator.
> 
> Any suggestions from your experience what kind of constructs might be
> good for this purpose?

You already have most of the data in structures right now - just move
it to the XML file and add the constraint data.  The PPD file then
just needs to reference the instance in the XML file (e.g. driver
name, ID, etc., like we already have...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com