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.
>>