IPP Mail Archive: Re: IPP> Document Object Spec Comments...

Re: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

From: Mike Sweet (mike@easysw.com)
Date: Sun May 04 2003 - 13:56:19 EDT

  • Next message: McDonald, Ira: "RE: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]"

    Hastings, Tom N wrote:
    > Michael wrote:
    >
    > I've never seen such a combination, but assuming that such a composite
    > printer object exists, it *should* be smart enough to route B&W jobs
    > to the B&W printer and color jobs to the color printer. If the job
    > gets bound to a single output device then the implementation is no
    > better than one that exposes multiple printer objects.
    >
    > <th>
    > I assume that a client submitting a single job containing a black and white
    > document and a color document to the same Printer wanted them to be printed
    > together. Perhaps, even asking for multiple copies collated, so that they
    > could be handed out at a meeting. So such a composite Printer shouldn't
    > split up a Job, sending one document to one device and the other to the
    > second device.

    <ms>
    I personally don't think that IPP provides any guarantee of documents
    being rendered by a single device; about the closest it *does* come
    is the multiple-document-handling attribute, but even then it only
    means that the final document will be combined, not that it must be
    output by a single device.
    </ms>

    > If the client didn't care whether the two documents came out together on a
    > single device as a single job, then the client should submit each document
    > to two separate Printers, where one controls a black and white device and
    > the other controls a color device.
    > </th>

    <ms>
    This is the more likely scenario anyways.
    </ms>

    >>...
    >>Then the client can decide to break the job into two jobs and submit
    >>each document as separate jobs or find another Printer (without
    >>having sent *any* document data for either document).
    >
    >
    > How is this different from the Send-Document case?
    >
    > <th>
    > The difference is that the client didn't send any data for the first (black
    > and white) document when discovering that the Printer can't accept the
    > second (color) document and print both of them on a single device.
    > </th>

    <ms>
    OK, so do your Validate-Job *before* creating the job. Either
    Create-Document or Validate-Job may fail for your color job on
    a black-and-white device. Doing the Create-Job + Create-Document
    method just has the added "benefit" of using up server resources
    and opening the server up to additional kinds of DoS attacks.
    </ms>

    > ...
    > But that, too, doesn't hold up. Nothing prevents the client from
    > mixing Validate-Job and Send-Document operations on-the-fly.
    >
    > <th>
    > Of course, a client can do a Validate-Job before each Send-Document, to get
    > the same effect as the Create-Document, Send-Data, except for the validation
    > across documents in the Job.
    > </th>

    <ms>
    Why would that even be necessary?
    </ms>

    > ...
    > <th>
    > Yes, it would be a good idea to define a new status code, so that the client
    > would know for sure not to try again for those implementations that have a
    > hard limit.
    > </th>
    >

    <ms>
    It doesn't even have to be a hard limit, it could be a limit that is
    determined on-the-fly based upon user quotas, active jobs, etc.
    </ms>

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Sun May 04 2003 - 13:57:38 EDT