Subject: IPP> Comments on the Model Document -Reply

From: Scott Isaacson <[email-masked]>
Date: Fri, 07 Mar 1997 11:59:42 -0700

Patrick,

Thank you for being willing to participate.   Some people are always just
to busy.  It is great to have your perspective.

>>> Patrick Powell <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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: [email-masked]
W: http://www.novell.com
************************************************************

---

From: Patrick Powell <[email-masked]>
Date: Fri, 7 Mar 1997 20:19:17 -0800 (PST)

OK, on consideration,  the different 'Interface URLs' are probably not a good
idea.

Patrick

---

From: Patrick Powell <[email-masked]>
Date: Fri, 7 Mar 1997 20:18:27 -0800 (PST)

Scott,  I believe there are times when complexity has to be exposed -
but you don't need to expose too much.

I hate to use an analogy,  but the IPP effort, as I see it, is trying
to reduce printing to a 'drive the car' model. Put in gas, turn the
key,  and go model.

However,  the motorist needs to know about the motor, gas tank, and oil
pump so that when the little red lights go on they can figure out what
is happening.

We still have a car - most of the users will just drive it.  Most of
them will NOT need to know about the insides.  But for explaining what
is supposed to happen, it is useful.

Ummm... having now put this analogy forward,  I might add that we DON'T
need the control panel of a 747, with 6000 lights, toggles, buttons,
and things.  We might want to put in a 'power takeoff' for adding
things...

Patrick Powell