IPP> Job-URI vs. Job-Id: How would you handle moving jobs?

[Jim Walker]

Jay Martin wrote:
> 
> Since the Job-Id approach implicitly uses the Printer-URL, then
> how would you handle moving jobs between Printers?  Wouldn't this
> present something of a showstopping problem?  How would the client
> keep track of the change in Job-Id, much less the change in Printer?
> 
> For printing systems using IPP, it would seem that the Job-URL
> approach would suffice quite nicely due to the inherent opacity
> of the job identification.
> 
> Comments?


Jay, I think that this is a very good question.  In our system,
jobs are independent of printers, and moving jobs is a simple
operation (from the client's perspective).  The "job identifier"
remains the same, the job is just directed to another printer.


I believe that by associating the job with the printer (by
identifying it with a <printer,ID> tuple) you would make
this problem very difficult.


Also,


> Robert Herriot wrote:
> 
> It seems to me that there are two solutions to this problem. Either
>    a) a job has a constant identification for its life or
>    b) an identification that changes when it moves.
> 
> In case a, it doesn't matter whether a job has a job-URI or a
> (printer-URI,job-Id), the same server manages the job for its duration
> regardless of the location of the job


I think that you are glossing over a subtle, but very important point,
here.  It is true that, if the job has a constant identification for
its life, the "same server manages the job ... regardless of the
location of the job".  HOWEVER, there is a difference, in my mind,
between having an independent job object referred to by an opaque
URL, and a (printer-URL,job-ID) tuple where the job is by definition
tied to that particular printer.  In the case of the former, the
job can be managed by a server that is independent of the printer
(cf, DAZEL).


> Case b may seem simpler because of the redirection that can
> be applied to Job-URI.  But this apparent simplicity hides the complexity
> of how long the forwarding-server keeps a record of a job that it no
> longer controls. The simplest solution for this case may be the same
> as for case a, namely the server keeps a forwarding record for the duration
> of the job.
> 
> I stand by my previous statements, that the cited advantages of a
> job-URI are based on speculation. I have not seen anyone provide enough
> detail for us to understand the full solution for the move-job
> problem.


I can point you to a print system that is in use today that uses
the concept of an independent job object (akin to a job-URL),
and it is successful in solving the move-job problem.  The job is
managed independent of the printer, making it very easy to move
the job, and retain its identity.


> I have no problem with a design that might make the solution of future
> problems easy as long as it doesn't affect the solution to current
> well-understood problems.


future problems solved today...
...walker



--
Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX