Patrick,
Thank you for being willing to participate. Some people are always just
to busy. It is great to have your perspective.
>>> Patrick Powell <papowell at dickory.sdsu.edu> 03/05/97 06:03pm >>>
> I think that the underlying model of the printer that is proposed in the
> Model document is too simple, and is in contradiction with the various
> attributes and values that you propose. It tries to avoid complexity,
> while at the same time the various details express information about
> components and interactions not currently part of the model.
I agree with this summary, but I don't think that it is the model that is too
simple (the simple model of Printer, Job, Document), but the added
complexity that we are adding on to solve every single feature of every
single distribute printing subsystem ever. That is what DPA tried to do.
We should remove complexity in our complex attributes, not add
complexity by modifying the model.
>>> Patrick Powell <papowell at dickory.sdsu.edu> 03/05/97 06:03pm >>>
> Note that this is NOT a rejection of your model, but an enhancement - I
> like a lot of the ideas, and am trying to make them easier to
> explain/specify.
You show a diagram with the following objects and their relationships
Printer
Input Queue
Active Job Handler
Physical Device
Administrator
Interface URL
If there a few attributes that have to be added to the Printer Object in IPP
in order to make the IPP Printer Object be an simple abstraction for some
somewhat more complex realizations, I would rather do that than expose
all of the different objects since there are LESS common characteristics
and interfaces for these implementation objects. We must do a better job
of describing the model rather than modifying the model.
>>> Patrick Powell <papowell at dickory.sdsu.edu> 03/05/97 06:03pm >>>
> ... on the format required, transport, etc.
I am not sure I understand the purpose of multiple URLs for different
formats multiplexed over different transports?
>>> Patrick Powell <papowell at dickory.sdsu.edu> 03/05/97 06:03pm >>>
> The Printer (well, actually it is a print server) will have a 'master queue'
> into which all incoming jobs are put. These jobs priority/requirements
> will be sorted, matched, etc., and then will be placed in the input queue
> or rejected.
One if the initial goals for IPP was that IPP could eventually be embedded
into network attached printers that had enough computing resources
(processor, disk, memory, etc) to support model. The vision was that
this included many of the middle to high end network printers that exist
today.
The rest of the objects that you describe in the modified model
do exist in many implementations with varied levels of functionality and
interfaces and features, however, the "End User" (the role described in
the requirements document) does not need to know about the existence
or status of these components.
My thoughts, I am sure there are others.
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************