Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Jay said...
>After reviewing Tom Hasting's most recent issues document, it is
>really starting to appear that "IPP" is simply the 1990's name
>for "DPA" in terms of scope and complexity.
>Does anyone else out there share this view?
Yes, I have express this sentiment when reviewing other IPP documents. I can't
"complain"
because I've been unable to participate as heavily as I'd like in the
extremely rapid pace
of IPP development, therefore, I haven't been able to contribute any
meaningful alternatives.
I'm still trying to pare back the Job MIB to something that will work in a
printer! It's where I'm
currently focused. (I guess someone has to bring up the rear ;-).
Just as an observation - and I'll admit to being parochial toward lower cost
embedded
controllers, not necessarily representing the "total" IBM or industry world of
printing - it seems
like not only DPA, but specifically the constant bringing of SERVER function
into the picture
is what makes it so complex. I'm not saying this is not valid or necessary,
but I feel like there
are already products developed or being developed on DPA (Tom even referenced
these
as existing applications that can't be "broken" when I recommended changing
JobState to
one object rather than 2). It's fine for DPA to cover all the complexities of
job sets, job ordering,
print pooling, holding 'till midnight, documents that make up jobs etc. etc.
etc..., but why do
we have to push ALL this into IPP? Why can't IPP facilitate web submission and
web feedback,
freeing network print from the LOCAL area network, and still let DPA
applications manage the
complex enterprise where and when appropriate.
Don't get me wrong - I feel DPA and DPA applications have a definite place and
a great value
in many large enterprises. I want IPP and DPA apps to interoperate. I just
don't want IPP to
*become* DPA (same goes for the Job MIB).
Harry Lewis - IBM Printing Systems