>
>Carl and Michael,
>
>I assume that this new OPTIONAL "document-number (1:MAX)" operation
>attribute is for use by the client in requests. If supplied, then it is
>the
>order that the client wants the documents to be printed, correct?
Yes. It should start at 1 and increase to the total number of documents (when
last-document=true). No holes or duplicates.
>
>Can the client supply the numbers out of order, i.e., submit document 3,
>followed by document 1, followed by document 2? What burden does that put
>on IPP Printers to accept documents in a different time order than they are
>going to be printed? Or MUST the client supply the numbers in
>monotonically
>increasing order, except when submitting more than one document in
>parallel?
I think that if you allow parallel Send-Documents, then getting them out of
order sequentially is just a special case. So I would say yes, a client can
supply the documents out of order. A Printer that doesn't want to accept this
burden could reject the "document-number" operation attribute as unsupported.
This puts the burden back on the client to serialize the transmission of the
documents.
>But it would also be useful to make "document-number (1:MAX)" an OPTIONAL
>operation attribute that the IPP Printer could return in responses, whether
>the client had supplied it or not. (We had the same output-only attribute
>in ISO DPA, called "document-sequence-number").
>
>What do you think?
Hmm... I have no objection, but what's it used for?
-Carl
>
>Tom
>
>
>-----Original Message-----
>From: Michael Sweet [mailto:mike@easysw.com]
>Sent: Thursday, October 14, 1999 06:03
>To: kugler@us.ibm.com
>Cc: ipp@pwg.org
>Subject: Re: IPP> Proposal: New document-number operation attribute for
>Send-Document
>
>
>kugler@us.ibm.com wrote:
>> ...
>> 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
>
>Actually, it doesn't even need to be multi-threaded to handle multiple
>connections; a state machine server (like CUPS) can do it, too.
>
>> ...
>> 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.
>
>We've actually been looking at this problem for our next
>implementation of CUPS, and it looks like your approach will
>definitely solve it elegantly.
>
>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products mike@easysw.com
>Printing Software for UNIX http://www.easysw.com
>
>