Some Jobs might consist of hundreds of documents (think of books, with graphics
objects). In cases where the operation turn-around time (latency) from client
to Printer is long relative to the time to transmit a document, it can be useful
to send multiple documents in parallel. On the Printer side, a multi-threaded
implementation, capable of processing multiple operations in parallel, may be
more efficient than a single-threaded one. These kinds of parallelism present a
problem with the Create-Job/Send-Document pair of operations. Specifically,
when Send-Document operations run simultaneously on multiple connections and/or
Printer process threads, documents within a Job might be received out of order.
To solve this problem, we propose a new operation attribute for the
Send-Document (and, by extension, Send-URI) operations. Specifically, Integer
(1..MAX) "document-number" . This is a document sequence number that begins
with '1' for the first document, and is incremented by one for each subsequent
document up to and including the document with "last-document"='true'. Thus,
when the Printer|Job gets the final document (last-document=true), it can
examine the document-numbers of the documents previously received to a) ensure
that all have been received, b) determine the proper ordering of the documents
within the Job.
The "request-id" attribute doesn't quite solve this problem since there's no
guarantee that request-id numbers are ordered or contiguous.
This new operation attribute would be OPTIONAL, with the understanding that if
"document-number" is not supplied it's up to the IPP client to serialize the
requests by synchronously transmitting one document at a time.
Carl Kugler
IBM Printing Systems Co