IPP> FW: Thoughts on the new Move-Job operation

IPP> FW: Thoughts on the new Move-Job operation

IPP> FW: Thoughts on the new Move-Job operation

Michael Sweet mike at easysw.com
Wed Mar 22 08:55:11 EST 2000


"Hastings, Tom N" wrote:
> 
> Michael, Ira, Bob, and I have been exchanging email on the Move-Job
> operation as a result of last week's IPP telecon.  We have a few
> issues left.  But here is where we are for tomorrow's IPP telecon,
> 3/22.

As usual, I won't be able to "attend" the telecon...  :(

My comments are below...

> ...
> ISSUE 01:  There is some debate as to whether to ALLOW the Move-Job
> operation to be supported when the job is in the 'processing' state.
> If it is allowed, it would be a MAY, not a MUST, because some
> systems will have problems with accounting if the same job-id is
> reused for the job again if some resources had been consumed.

See my other comments on this; to summarize, I think we'll need to
allow the "move-job" operation to create a new job-id and job-uri
as needed by the implementation.  The new job-id should not be
REQUIRED, since this will open up another can of worms with
accounting and job persistence - e.g. doubling the server's disk/
memory requirements if document files are persistent until purged.
(something that CUPS 1.1 supports)

> ...
> 2. In case the Printer defaults are different for the new Printer,
> we need to specify that the new Printer's defaults will be used when
> the job is processed, even if they differ from the defaults of the
> old Printer.

This makes sense, since in the absense of job template attributes the
printer defaults (which the client may be oblivious to) are used
anyways by Create-Job, Send-Job, and Send-URI.

> ...
> "printer-uri" (or old "job-uri") and the new "printer-uri".

Which should be called "job-printer-uri" to avoid ambiguitity with
the printer-uri used to identify the job.

> ...
> ISSUE 02:  Ok to REQUIRE that the "ipp-attribute-fidelity" operation
> attribute be copied to the Job object, if the Move-Job operation is
> supported?

Yes.  Similarly, if the new printer object does not support the
attributes provided, and ipp-attribute-fidelity is true, then
a client-error-conflicting-attributes error needs to be returned
and the job is not moved.

> 6. Finally, do we want to make Move-Job be like the Job Creation
> operations and specify that the Move-Job response MUST be the same
> as the Print-Job response:

Yes.

> ...
> ISSUE 03: Ok that Per-Job Subscriptions are automatically updated to
> be for the new job (whether the job-id changes or not)?

This is a sticky problem; if the job-id (and job-uri) changes, then
the recipient of the notifications may not know what the notification
is for (e.g. I am subscribed to job 5, I move the job, now I am
subscribed to job 6???)

Obviously we'll need a "move-job" event subscription, and that
event needs to provide the new job-id, job-printer-uri, and
job-uri attributes for the job (whether the job-id has changed or
not)

> ISSUE 04:  Should there be a new 'job-moved' event or is moving a
> job, just another operation that generates the 'job-created' (along
> with Print-Job, Print-URI, and Create-Job)?

I think we need it.  If we end up requiring a new job-id (something
I'd rather not do), then we also need to add a new job-state value
for "job-moved", since "completed", "cancelled", and "aborted" do
not make sense.

> 10. ISSUE 05:  For all of us to consider:
> 
> Should we add this operation to the Set Job and Printer Spec
> (because it is similar to scope and usage to the Set-Job-Attributes
> and Set-Printer-Attribute spec), add it to the Administrative Set2
> spec, or keep it as a separate spec?

It might make sense to include it there.  However, I think we've
identified enough issues that move-job may be large enough to make
it a separate spec all by itself.

> ...
> spec to go out for last call soon (as soon as we agree on the
> collection syntax encoding).  On the other hand, if we are far from
> ...

Once again, let me voice my *lack* of support for the collection
syntax, as it will needlessly complicate implementation and support
of IPP.  The new "printer-xri-supported" attribute could use a new
compound value tag ("xri") that would provide a URI and two keywords
to cover what is needed for that attribute (and other similar
situations we're likely to run into)

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



More information about the Ipp mailing list