Subject: PWG-ANNOUNCE> how are optional units managed?

From: "Norbert Schade" <[email-masked]>
Date: Wed, 9 Jun 2004 15:10:02 -0400

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: [email-masked]

---

From: "Farrell, Lee" <[email-masked]>
Date: Wed, 9 Jun 2004 15:23:50 -0700

Hi Norbert,
 
Could you please move this discussion to the UPDF reflector?
 
Unless there's something I'm missing, it seems more appropriate there.
 
Thanks,
 
lee

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Norbert Schade
Sent: Wednesday, June 09, 2004 12:10 PM
To: [email-masked]
Subject: PWG-ANNOUNCE> how are optional units managed?

Glossary

A base unit is the printer itself without anything attached to it
(except RAM, which is very predictable).

The challenge:

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.

Regards

Norbert Schade

Norbert Schade

Software Manager

USA
tel. 1-781-370-8929
fax. 1-781-370-8990