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

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

[Pete Zannucci]

All,

I have put an updated version of the lower level architecture
diagrams in the pwg site.

ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch1-121302.jpg
ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch2-121302.jpg

I realized when I looked at them the points that Michael
Sweet was making because the bidi drawing had a connection
directly to the printer which was incorrect.  I updated page
2 to more accurately reflect what the thought was.  Sorry
for any confusion.

As far as the notification and event management scheme,
we have been looking at http://evlog.sourceforge.net/  for
starters.  It would have to be able to handle large volumes
of information though along with a lot of additional function
that we haven't even started discussing yet.

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.

Dynamic capabilities would definitely require additional function,
possibly processes, to enable the system (most likely a local
store of sorts) updated with the latest device information.  Of
course there are other ways to do this but I would worry that
if we don't have a current configuration cached, in some instances,
the amount of time to initiate a print job may become too large,
especially if we are going to populate dialogs for the user based
on the current settings.

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.

Just a couple of thoughts on dynamic capabilities.

Thanks,


Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com

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

[Michael Sweet]

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