After reading Peter's document and your email, I don't feel that there is a
"different understanding".
In Peter's "Current" scenario, there are 9 steps. Steps 1-7 are what you
describe as printer browsing, and "some separate application possibly
initiated through a web browser" which selects, installs (including
download), and sets up that printer for printing by any application on the
desktop.
Steps 8 and 9 are just running any application and printing. This is what
you suggest as: "When a user wishes to print from an application, I
would expect that the list of available printers might include some IPP
printers, but the application not need be aware of this difference. The
same GDI API's would be supported by the IPP driver"
I don't see a difference between what you describe and what Peter had
under "Current". However, in order to support the automatic driver
download problem (ie from the net not from a floppy or CD) we need to
have some way of connecting the correct driver with the IPP Printer.
Some have suggested storing the Driver in the directory. This would be
OK if there were a new entry type called a Driver that contained info
about the driver and where the actual software was located, but it
would not be OK if the Driver were stored "as an attribute of the Printer
entry". It is possible (as Peter suggests) to get by without the extra step
of more objects in the directory, just to point to the correct driver directly.
However, I would suggest one level of indirection. This is why I
suggested some sort of DEVICE ID in the directory entry. With this, the
"install wizard" could go out and find the right driver (there might be an
updated version). This would free up the admin from trying to update all
Printer entries with the correct pointer to the correct driver if there ever
is a change.
I propose not getting into this mess and just leave enough info in the
Printer object (and its directory entry) which is the Device ID so that the
correct driver can be found. I don't think that we should force it to point
to the correct driver or go the the trouble of trying to create a new object
called Driver. Remember that a Driver can be many files (in windows it
can be a .DRV, some .DLLs, and some config info such as .PPDs).
There IS a difference when you talk about an IPP Aware Driver vs a Non
IPP Aware Driver. Both could be used to realized IPP functionality with
existing GDI interfaces and applications.
IPP Aware Driver
In an IPP Aware Driver, the driver could implement the IPP protocol
directly (and assuming HTTP) be written to HTTP interfaces and just do
the operations directly. In this case the Driver has to know the Printer
URL for which it is configured (set at install time or modified sometime
later through a Driver provided interface). This would require new driver
development obviously.
IPP Non-Aware Driver
This scenario is just like any of the existing drivers today that are able to
format jobs that are "redirected to network printers". There is some tool
that creates a new "port" which looks to the driver just like any other
hardware port. The driver is configured to write to that port, but then
uderneath that port is a network redirector or a network provider that
does the right thing. This redirector or provider can be configured
independently of the driver to point to some other network printer. In the
IPP model, this scenario would require an IPP redirector or an IPP provider
but it would work (which would be some development) but it would work
for ALL drivers and ALL applications just as redirected printing works
today.
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson@novell.com
W: http://www.novell.com
************************************************************
>>> Robert Herriot <robert.herriot@Eng.Sun.COM> 12/17/96 06:25pm >>>
After reading Peter Zehler's document, I think that we have different
understandings of how IPP will work on a PC. I have assumed that the
procedure that a user follows for finding a printer is separate from
the print operation.
For printer browsing, I would expect there would be some separate
application possibly initiated through a web browser which would allow
a user to specify printer characteristics and get back a list of
printers. A user could then add one or more of these printers to the
desktop. The operation of adding such a printer would install any
necessary drivers to the PC, like any other add printer operation except
that the drivers should come over the network and not request that the
user insert the CD-rom.
When a user wishes to print from an application, I would expect that
the list of available printers might include some IPP printers, but the
application not need be aware of this difference. The same GDI
API's would be supported by the IPP driver.
What do others think? Do you agree with my understanding or do you
see things the way Peter does?
Bob Herriot
> From jkm@underscore.com Sat Dec 14 17:06:47 1996
> Date: Sat, 14 Dec 1996 20:06:49 -0500
> From: JK Martin <jkm@underscore.com>
> Organization: Underscore, Inc.
> X-Mailer: Mozilla 3.0 (Win95; U)
> MIME-Version: 1.0
> To: IPP redirector <IPP@pwg.org>
> Subject: Re: IPP> RE: Printer Instance Creation/Installation
> References:
<"<E078B13281E2667C>E078B13281E2667C@X-WB-0311-MS3.XEROX"@-SMF->
> Content-Transfer-Encoding: 7bit
> Sender: ipp-owner@pwg.org
> X-Lines: 22
>
> Zehler,Peter wrote:
> >
> > All,
> > I have placed a document that discusses these issues in the
> > "contributions for discussion directory". I have an MS Word and
> > a postscript version of the document. I need to convert the
document
> > to the Acrobat format. I need help with this since I do not have an
> > Acrobat writer.
>
> An Adobe PDF file now exists for the file(s) described above:
>
>
ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/IPP-driver-issue.pdf
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03015-4915 | Web: http://www.underscore.com
-- > ---------------------------------------------------------------------- > >