Carl,
Your first solution now requires a whole IPP client implementation in your
printer, a considerable extra burden, and what do you do if the job is
accepted by the New Printer, but with some unsupported attributes? How much
do you report back to the original client?
The second suggested solution seems to require that you return all your
print data to the client, not such a good idea if you have several documents
or is doing print-by-reference (and the data has already been fetched by the
printer).
Hence, both of your suggested solutions have issues (or limitations if you
want).
Not sure I have any better solution to offer though...:-(
Carl-Uno
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Monday, July 10, 2000 2:14 PM
To: ipp at pwg.org
Subject: Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
Printer A dmin (Set2) spec
"Hastings, Tom N" <hastings at c...> wrote:
> I added Move-Job (renamed to Redirect-Job since no job movement is
required)
> to the Job and Printer Administrative Operations spec that I just posted.
...
> This operation is limited to redirecting a job to another Printer on the
> same server.
This limitation seems a bit restrictive, particularly since the IPP Model
doesn't even define a server object.
I thought of a couple of ways to do a more general, true Move-Job operation
(maybe these have already been discussed and I've missed it). Given a
Client, an Old Printer, and a New Printer, the object is to get the job
from the Old Printer to the New Printer.
1) A Move-Job request sent from the Client to the Old Printer causes the
Old Printer to become an IPP client to the New Printer. The Old Printer
sends a Print-Job request to the New Printer. When the Old Printer
receives the Print-Job response from the New Printer, it returns this to
the Client as the Move-Job response. (If the job was accepted, this
response includes the new job-printer-uri, job-id, and job-uri, so the
Client can now track the job on the New Printer.)
2) Instead of a new Move-Job operation, define two new operations: one
which "inhales" the Job from the Old Printer into the Client, and another
which "exhales" it from the Client to the New Printer. What should these
new operations be called? Hmm, ..., ... ! IPPness indeed! On second
thought, maybe the exhale operation is redundant: the client could just do
a Print-Job. So, all we need is a new Get-Job operation that allows the
Client to pull the complete Job back from the Old Printer so that it can be
sent to the new Printer with a Print-Job request.
Okay, what are the fatal holes in these proposals?
-Carl