IPP> Proposal: New document-number operation attribute for S end-Document

IPP> Proposal: New document-number operation attribute for S end-Document

IPP> Proposal: New document-number operation attribute for S end-Document

kugler at us.ibm.com kugler at us.ibm.com
Wed Oct 20 11:21:26 EDT 1999



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
>>
>>
>





More information about the Ipp mailing list