IPP Mail Archive: RE: IPP> PRO,MOD> User model for clients

RE: IPP> PRO,MOD> User model for clients

Babak Jahromi (babakj@MICROSOFT.com)
Tue, 28 Jan 1997 10:32:29 -0800

The issue you are raising is a valid one. The problem is not just
printing from the borwser. What it you want to print an Excel spread
sheet to your favorite IPP printer? Even though IPP printing can be
centered around the browsers, we still need to let other apps print as
well. Which implies that the IPP printing capability has to be
implemented as an OS extension, which all apps, including the browsers,
can take advantage of. Since we cannot expect the appsto be modified,
the OS would have to encapulate the knowledge.

Babak

>-----Original Message-----
>From: Randy Turner [SMTP:rturner@sharplabs.com]
>Sent: Tuesday, January 28, 1997 9:50 AM
>To: ipp@pwg.org
>Subject: IPP> PRO,MOD> User model for clients
>
>I was wondering if anyone has modeled the user interface side of
>browser-based printing using IPP. One of the fundamental reasons
>we are thinking about HTTP is the existing installed base of
>browsers. I think we have accepted the fact that we will require
>additional capability on HTTP servers that also host IPP print
>services; however, since there are far more client browsers than
>HTTP servers, this wasn't a bad trade-off, so really what we are
>doing is leveraging the installed base of browsers on the net.
>
>The protocol/white paper that Roger published talked about using
>the HTTP "POST" method for job submission, and I think that is
>what most of us assumed would be used for IPP. The existing
>installed base of browsers have designed their printing subsystems
>to be platform-independent (i.e, under Sunos/Solaris they default
>to lpr/lp, and under Win95/NT, they use the windows print system).
>
>When the user is looking at a particular page (any page from any
>content hierarchy) and wants to print a particular page, he/she
>will be very tempted (using the currently installed base of
>browsers) to print the way they are used to printing pages, via
>a "Print" windows control or from the "File" pull-down menu. If
>we are using the "POST" method, and utilizing some form of
>multipart FORM "POST" through IPP, how do we enable this for any
>page the user might be viewing? If I'm looking at a copy of the
>online Wall Street Journal and want to print information about
>a particular companies earnings report on a remote IPP printer,
>using the built-in "Print" facility within the browser will not
>work, unless the user has previously installed some type of
>Windows networked IPP redirector in the system, but I don't think
>we can require this, at least in the prioritized set of things we
>want to do, the driver loading has been moved down the list. And
>this would not be a cross-platform, open way of handling this.
>
>Maybe I'm missing something very simple, but we are modeling this
>type of usage model and I'm having some concerns about not being
>able to "tailor" the client environment for IPP printing, which
>would all but eliminate alot of the rationale for using HTTP.
>
>Let me know if I've completely forgotten something that we've
>already worked on, I have missed a couple of teleconferences.
>
>Randy
>
>--
>Randy Turner
>Network Architect
>Sharp Laboratories of America
>rturner@sharplabs.com