You've done a great job in describing your position in your response
to Harald on this topic. It wasn't until I read your fine posting
that it finally dawned on me where I was having some problems with
the directions the IPP was taking.
It is possible to describe any one of the vast majority of today's
printing systems as having one of the two following models:
Model A: client ---> printer
Model B: client ---> spooling server ---> printer
Where I think IPP gets into real trouble is that it tries to achieve
these goals simultaneously:
1. Provide all printing features required by 99% of the world's
population;
2. Assure that all such defined features can be implemented in
a desktop printer costing $150 ($119.99 at Wall-Mart);
3. Make all of this happen by mid-1997.
How many times have we heard statements like:
"We can't go that route, it's not possible in a desktop printer."
Seems like we had better come to grips with the possibility where IPP
should only attempt to address "Model B" above; then, as hardware
technology decreases in price, allow desktop printers to catch up.
That is, let IPP address the "client ---> spooling server" portion of
the model, and develop a cheap, simple, and fast protocol to deal with
the "spooling server ---> printer" side of the model.
Sure, one could take sufficient time and resources and ultimately
define a printing approach that scales from my mother's direct-attached
ink-jet printer all the way up to the 200+ page-per-minute laser screamers
in Fortune 10 companies, but the age-old question arises:
"Why?"
Just because you CAN do something doesn't mean you necessarily SHOULD.
My company has plenty of experience with large Enterprises using LPD
on every type of client in the Enterprise--including Windows 3.1--that
feed large spooling servers. These servers then use a plethora of
protocols to effect the print jobs on a wide variety of both network
and direct-attached (serial/parallel) printers.
And you know what? Those companies are crying for a standard protocol
to talk to the printers. Lack of features on the client side is not
even on the horizon for them.
One last thing:
>>KISS.....
>
>We agree. The hard part is deciding for which party to make it simple:
>the client or the server/printer.
It's starting to look like NEITHER side is going to be simple. And I
really believe that at least one side CAN be simple...if we step back
and re-evaluate some of the directions we've been taking.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------