"Hastings, Tom N" wrote:
> ...
> 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?
I'm not sure that "resubmit-job" is the right name; for persistent
jobs (when the files are still around), I'd expect a "resubmit" to
try printing a previous job (like the current "restart-job" operation
does.) I think "move-job" would be less confusing.
As for the issue of moving a job to a remote IPP server, I think we
can restrict movement to the same server, e.g. moving a job from
port 1 to port 3 on a parallel print server, or (in the case of CUPS)
moving from one queue to another. Redirection to a different server
opens up a whole host of issues that the current IPP specs don't
cover.
With that said, if set-job-attributes allows the job-printer-uri
to be changed, but only to another URI on the same server, then the
only issue is if the job-id attribute would change. The current
IPP spec only requires the job-id to be unique for each printer
object, so potentially that might be an issue (it isn't for CUPS,
nor IIRC for the HP JetDirect IPP servers) One (simple) solution
is to return the job-uri and job-id attributes in the response
data from set-job-attributes all the time; the client would then
be responsible for using the new URI and ID in the future?
[I'm just trying to avoid yet-another-extension-operation in CUPS]
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com