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 at sharplabs.com