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 at easysw.com
Printing Software for UNIX http://www.easysw.com