[Printing-architecture] Lower level diagram update (bidi update)
pzaan at us.ibm.com
Fri Dec 13 12:32:51 PST 2002
I have put an updated version of the lower level architecture
diagrams in the pwg site.
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.
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 at us.ibm.com
More information about the Printing-architecture