Don Wright wrote:
>> Randy Turner said, in part:
>> >...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.
>> 1) Browsing for printer status, queue status, etc. requires
> nothing additional on the client.
of a directory service, which is what we are planning on. However,
this may not be true with some existing non-LDAP capable browsers.
>> 2) Printing to a remote printer from an application on the
> client (eg Word, Lotus 123, etc.) requires something
> I'll call an IPP driver to be installed on the client. Perhaps
> this is downloaded from the Web or comes as a part of
> a new operating system but there's got to be some type
> of "redirector" installed. "Push" and "Pull" printing can be
> accomplished from a properly written WEB page and
> an unassisted WEB browser, but transparent printing
> from an application to a WEB printer requires additional
> software.
The above sentence with regards to "properly written WEB page"
is not germain to IPP. We don't want content architected to be
compliant with IPP. WEB authors should feel free to do whatever
they want and not constrained by having to know how to have their
content printed.
>> This is consistant with the directions I have seen from
> several vendors working on solutions in this area. I
> don't think any solution (HTTP, TCP Stream, etc.) can
> solve the problems you mentioned without a new
> "IPP Driver" being installed on the client.
I think this statement is true as well, and if we want to rely
on HTTP and browsers to deploy IPP, it complicates things
dramatically. The user now has to know (or someone has to
know) what type of browser (and platform the browser is running
on) in order to properly provide the appropriate "driver" which
I'm not sure if the term even applies to anything except the
windows printing environment.
I think the best technical solution for this would be to ask
browser vendors to rethink their logic when the "Print"
button is selected in their respective user interfaces. We need
a hook into this process (maybe some sort of java applet) that
handles printing over IPP. If the applet is loaded, it tries
IPP, and if not loaded, it defaults to whatever platform
printing environment is in use. Of course, this would render the
existing installed base of browsers incapable of doing IPP.
The driver solution is going to be complicated and frought with
issues (possibly licensing), and platform-dependence questions.
I'm not saying it's impossible, it just severely gets in the
way with our focus on designing a simple IPP.
Some of the issues with driver installation might include:
1. What browser is the user using?
2. What OS platform is the browser installed on?
3. Where do I get the driver?
4. Who will write the drivers and are there
licensing issues involved?
5. Will each IPP server have to have all possible
platform/browser combinations of drivers loaded to
support the widest possible audience?
6. Will driver installation require administrator
intervention?
7. Will the user have to restart the OS or browser
or both after installation? (and this varies depending
upon the OS/print driver environment).
These are just off the top of my head, maybe someone could
elaborate on these.
Randy
>> Don
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com