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?
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?
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?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Thursday, October 14, 1999 06:03
To: kugler at us.ibm.com
Cc: ipp at pwg.org
Subject: Re: IPP> Proposal: New document-number operation attribute for
Send-Document
kugler at 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 at easysw.com
Printing Software for UNIX http://www.easysw.com