No, just make the IPP implementation easy enough, so most low end
printers can afford it. This again implies not re-inventing the wheel. I
also see nothing wrong with letting the server be hooked to Internet,
passing the data to the printer via USB, parallel port, Ethernet, etc. I
don't see a dying need for the printer boxes to be hoocked to the
Internet directly.
>----------
>From: Angelo_Caruso at wb.xerox.com[SMTP:Angelo_Caruso at wb.xerox.com]
>Sent: Monday, January 06, 1997 2:56 PM
>To: ipp at pwg.org>Subject: RE: IPP> What is it we really need?
>>Babak,
>>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 at pwg.org>To: "'rdebry at us.ibm.com'"; "'Alex Bochannek'"
>Cc: Babak Jahromi; "'ipp at pwg.org'"
>Subject: RE: IPP> What is it we really need?
>Date: Monday, January 06, 1997 1:57PM
>>>----------
>>From: Alex Bochannek[SMTP:abochann at 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
>>>>>