Re: [Printing-architecture] Lower level diagram update (bidi update)

[Michael Sweet <mike@easysw.com>]

Pete Zannucci wrote:
> ...
> Capabilities is another subject altogether.  Since using .ppd
> files is the current implementation under CUPS, nobody has
> really started to discuss how to tie in dynamic capabilities
> from either a printer or a driver into the system.

Actually, several vendors have implemented this within CUPS by
actually updating the PPD file on-the-fly with the current
printer configuration.  The interface is straight-forward and
allows for a (relatively) small static representation of the
current capabilities which provides extremely fast access to
the information with little overhead.  Updates can be made
asynchronously via background processes or at print time.

 > ...
> It would be nice if our solution didn't need to have multiple
> drivers configured between systems and worry about keeping them
> all in sync. if wanted to get the properties in a networked
> environment. This will likely be up for debate when we start
> working out the issue of client vs. server side rendering though.

One of CUPS's major "selling" points is that the clients don't
maintain a local copy of the printer configuration, just the
basic information (URI, name, description, location, make/model,
type) to allow the user to choose the printer.  The client then
grabs the current PPD file for the printer via HTTP and/or gets
additional IPP attributes directly from the server for that printer
queue.

Another advantage of this architecture is that it can also support
client-side rendering assuming that client has the driver programs
locally installed - the PPD file determines what filters are run
and how they interact with the device.  Unfortunately, client-
side rendering does not allow for bidirectional communications
with the printer, and that is something we will *not* be adding
to CUPS for (obvious) security reasons, so the client-side rendering
might be limited to the PS/PDF/image RIP'ing, although the overhead
of transferring raster data over the network is prohibitive...

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