Tom wrote:
>-----Original Message-----
>From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
>Sent: Tuesday, October 19, 1999 16:36
>To: Hastings, Tom N
>Cc: Michael Sweet; ipp at pwg.org>Subject: RE: IPP> Proposal: New document-number operation attribute for
>Send-Document
>>>>>Tom-
>>>>>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.
>>TH> Well, an existing client is just going to ignore the "document-number"
>operation attribute as it is supposed to do for any operation attributes it
>doesn't recognize. Though perhaps, an IPP Printer might reject a second
>Send-Document when another Send-Document is already in progress but hasn't
>completed yet. Perhaps we need to clarify which status code the IPP Printer
>returns in this case (or add a new status code).
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 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>>>>>