In note 1 I already mentioned that UPDF is supposed to be extensible.
That goes for human languages, but for optional units as well.
Glossary
A base unit is the printer itself without anything attached to it (except
RAM, which is very predictable).
An optional unit is anything, which can be attached to the base unit or
exchanged like optional trays, a duplexer or a finishing unit.
The challenge:
Most other concepts have to know about optional units before the printer
driver is compiled.
That is a stolid architecture, as you never know, which optional units may
come up after the first launching of the driver and device package.
There are a few concepts out there, where you can add an optional unit to an
existing installation and it will get merged to it. The problem is detaching
it again. Imagine a base unit, which can feed Letter and A4, and an
additional tray, which can feed Letter and A5. merge the sizes to one list
and detach the optional unit. Will Letter size be supported after the
removal?
That's what brought us to separate descriptions for optional units. The idea
is to keep the description separate. So it can be detached without any
problem.
An optional unit can be described based on the same set of schemas as the
base unit. Just the configuration instance is different (the configuration
of the base unit can refer to more modules).
That allows it to mirror the real world as much as possible: you connect a
real optional unit to a real device --> you add a configuration piece of the
logical optional unit to the logical base unit.
So the main keyword here is Extensibility.
Regards
Norbert Schade
Norbert Schade
Software Manager
Oasis Semiconductor, Inc.
201 Jones Road
Waltham, MA 02451
USA
tel. 1-781-370-8929
fax. 1-781-370-8990
email: norbert.schade at oasissemi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pwg-announce/attachments/20040609/5608cb74/attachment-0001.html