I agree that a low-end printer can not be expected to provide the level
of job queueing and manipulation that a full blown server can provide.
But, ultimately one must transfer the job data to the "same old
printer box". How then do you propose we get the data to the printer?
Are you proposing that IPP be reserved for those customers who are
lucky enough to have a spare NT server off of which to run a parallel
cable to their printer?
Angelo
----------
From: ipp-owner@pwg.org
To: "'rdebry@us.ibm.com'"; "'Alex Bochannek'"
Cc: Babak Jahromi; "'ipp@pwg.org'"
Subject: RE: IPP> What is it we really need?
Date: Monday, January 06, 1997 1:57PM
>----------
>From: Alex Bochannek[SMTP:abochann@cisco.com]
>
>Well, I think it became quite clear from Angelo's email, that the
>largest number of implementors (the folks who write the printer code)
>will most likely not have the option of using anything even close to a
>"stock HTTP server". They probably have better tools to write code
>straight to a socket API than to their own HTTP server
>implementation. And I can tell you from very recent experience that
>printing directly to a printer, circumventing the intermediate step of
>a print server, is not only something that small shops do since at a
>certain point, print severs just don't scale anymore.
How can the squeezed, embedded server code in a printer box ever be a
match for the kind of service a "print server implemented on a computer"
can provide? We just saw an example of why a print server trapped inside
a printer box can never match a print server inside a computer: The
"printer" guys have to laboriously write ancient C code on top of TCP,
while the "computer" guys have lavish tools and technology, like ISAPI,
ActiveX, Java, Denali, etc. available on their "computer" platform.
If anyone has solved a scaling problems with an NT 4.0 print server and
has got a better performance by removing the server and routing the
clients directly to the same old printer box, please send me the case
study.
Babak
>
>