IPP Mail Archive: RE: IPP> RE: MOD - Push back on simplifying Print operation response

RE: IPP> RE: MOD - Push back on simplifying Print operation response

Babak Jahromi (babakj@MICROSOFT.com)
Fri, 21 Feb 1997 12:35:12 -0800

Well, I think the thins client (NC) platform might be a great dream, but
I doubt any IPP member would want to spend time desinging ONLY for a
platform that has currently almost zero market share.

Ideally we would like to cover both, without making any sacrifice for
the %99 of the cases, namely the traditional desktop OS.

Babak

>-----Original Message-----
>From: Harry Lewis <harryl@vnet.ibm.com> [SMTP:harryl@VNET.IBM.COM]
>Sent: Friday, February 21, 1997 7:05 AM
>To: ipp@pwg.org
>Subject: IPP> RE: MOD - Push back on simplifying Print operation response
>
>Sorry for the multitude of embeds, but this thread touches on something
>that has been bothering me about IPP. I'm not judging which is the right
>or wrong approach, but either we're building IPP for the scenario where
>standard desktop applications (i.e. Babak's response), run on a
>traditional desktop OS but the WEB underlies communications and print
>submission *OR* we're building IPP for the NC (thin-client) world where
>the WEB *IS* the OS and applications or applets, which have been modified
>to run in this environment, now use print services based on IPP.
>
>Or both, inevitably staged, based on Microsoft's NT5.0 direction.
>
>Where is the real focus of IPP?
>
>>Isn't what you call "print submission GUI" the everyday applications
>>people use? like Word, Excel, Corel, Quicken. etc. etc.?
>>
>>So I wouldn't plan on changing any of it!
>>
>>Babak
>>
>>>-----Original Message-----
>>>From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
>>>Sent: Thursday, February 20, 1997 3:27 PM
>>>To: ipp@pwg.org; hastings@cp10.es.xerox.com
>>>Subject: Re: IPP> MOD - Push back on simplifying Print operation response
>>>
>>>
>>>>
>>>> My concern is that either:
>>>>
>>>> 1. User friendly implmentations will make additional protocol calls
>>>> to get job and printer status. That means that each Print operation
>>>> will require three calls, not one. If we layer on HTTP that means
>>>> a new session startup/teardown for each of the three calls.
>>>
>>>My assumption is that the GUI from which the Print submission is made is
>>>a different process from the one showing status in most cases. In such an
>>>environment, the Print submission GUI would probably not inform the
>>>job status GUI about the changes. The primary issue is whether a print
>>>submission GUI (or command) would inform the user of the special case
>>>you site below where the printer is stopped and needs attention before it
>>>will resume printing.
>
>