We discussed your issue on the IPP telecon this Wednesday, and concluded
that it is better to add an operation to resubmit a job to another Printer,
rather than trying to do it with a Set operation. There are several reasons
for preferring an operation:
1. If the resubmission fails, then there is a lot of error information that
should be returned to the client, but can't be returned in a Set response.
It really needs a new operation (Resubmit-Job) that can return the errors.
Also there maybe a need for the new Printer to assign a new "job-id". Which
should be returned in the response. But returning a "job-id" in response to
a Set operation seems too unexpected.
2. Defining significant side effects (actually actions) with the setting of
an attribute is against our principle of having minimum side effects.
So should we define a Resubmit-Job operation? We had one in ISO DPA, but it
is really hard to implement when the target is a different Printer (on a
different host), since the Printer has to become a client and submit the Job
object to another Printer (probably using the Print-Job or
Create-Job/Send-Document) and mirroring the responses back to the original
client in the Resubmit-Job response.
Comments?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Wednesday, February 23, 2000 09:36
Cc: ipp
Subject: Re: IPP> OPS - Minor issues for the Set Job and Printer
operations spec
"Hastings, Tom N" wrote:
>
> For the IPP telecon today and email discussion:
> ...
Also, the "job-printer-uri" attribute needs to be read/write for
set-job-attributes; otherwise there is no way to change the
destination of a job. The current spec shows "job-printer-uri"
in the read-only table...
Unfortunately I'm not available for this afternoon's telecon...
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Fri Feb 25 2000 - 04:56:33 EST