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

[Babak Jahromi]

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 at vnet.ibm.com> [SMTP:harryl at VNET.IBM.COM]
>Sent:	Friday, February 21, 1997 7:05 AM
>To:	ipp at 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 at Eng.Sun.COM [SMTP:Robert.Herriot at Eng.Sun.COM]
>>>Sent:	Thursday, February 20, 1997 3:27 PM
>>>To:	ipp at pwg.org; hastings at 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.
>
>