Peter,
> I am prototyping IPP on a printer that can only accept and process a
> job at a time. I chose this printer specifically to check the lower
> bounds of an IPP implementation.
>> [...]
>> It is true some clients will be denied service while the printer is
> busy. All services must handle the "capacity + 1" problem. IPP seems
> to handle this problem.
How does IPP handle the problem where a printer implementation only
accepts a single connection at a time, where all other connection
requests are denied (or ignored) until the current job has completed?
In the marketplace today, there are *lots* of printers with network
interfaces that accept only a single LPD connection at any one time;
if a job (or any other LPD service request) is being handled, any
connection attempt simply fails with a TCP-level "time-out" indication.
As client software developers, this situation gives us tremendous grief,
as we are unable to discern between "the printer is too busy to answer
you right now" and "the printer is not responding on the network".
It is my ardent hope that printer vendors strive to develop network
printers capable of saying "I'm too busy right now, try later", rather
than simply ignoring the connection attempt.
> There is still the issue for the application to determine when it
> should time out. IPP level print job submission operations should help
> accomodate application level timeout detection.
Thanks for raising the issue of application time-out, Peter.
To me, this aspect of the IPP protocol could be the kiss of death,
whereby submission of a print job is handled in multiple, independent
transactions.
Lest we forget, one of the *biggest* problems facing the average user
is controlling time-out values for printers when those printers do not
have a decent protocol with which to determine when a job is done (or
has aborted, or whatever). Our experience has been that users absolutely
despise such required "fine tuning" of a printer's operational parameters.
How will this problem scenario be handled by the typical IPP implementation
within a network printer with no spooling capability (ie, can process only
a single job at a time):
1. Client executes a "CreateJob" operation on the printer
2. Client sends the first of three documents to the printer.
3. Client crashes...never to return.
If the answer is something like:
"The printer will have to use an internal time-out parameter to know
when to abort an in-process job submission, and that parameter will
have to be exposed to the system manager for potential modification."
then I'd suggest we haven't really come very far in advancing network
printing.
This is probably my biggest concerns with using HTTP as the basis for
a network printing protocol, at least when an operation spans multiple
independent transactions between the client and the server.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------