Tom, you're confusing me here. I'm talking about whether or not a client
includes "document-number" in a REQUEST. An existing client that doesn't know
anything about "document-number" will obviously never send the "document-number"
attribute so the IPP Object will never return it as unsupported. So I don't
understand what you mean by an existing client ignoring "document-number".
Presumably, existing clients do the Create-Job, Send-Document, Send-Document...
series of operations synchronously and sequentially. So the fact that they know
nothing of "document-number" shouldn't hurt anything.
Presumably, any Printer that doesn't support "document-number" (including
existing Printers), will return any "document-number" operation attribute
supplied by a client in the Unsupported Attributes response group, but otherwise
ignore the attribute. A client that receives "document-number" in the
Unsupported Attributes response group should not expect the Printer to be able
resequence Documents within a Job and therefore should avoid any attempt to
parallelize or pipeline the requests. Instead, it should send the requests
synchronously, doing one Send-Document, waiting for response, doing the next
Send-Document, etc.
>
>
>>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?
>
>TH> What happens if a client submits multiple documents in parallel and
>doesn't supply the new "document-number" attribute. This response
>"document-number" would indicate the order that each was going to be
>printed. But perhaps that isn't sufficient justification to have the
>document-number come back in the response.
I agree, not sufficient justification.
>Perhaps, instead, we REQUIRE the
>client to supply the new "document-number" operation attribute if it submits
>a Send-Document before completing a previous Send-Document?
Yes, sounds good to me.
-Carl
>
> -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
>>
>>
>