Michael wrote:
>
>kugler@us.ibm.com wrote:
>> ...
>> > 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.
>
>When we approached this topic before, we had a lot of discussion
>about how to implement this. IIRC the issues were:
>
> 1. The job-id and job-uri might change, depending on the
> implementation.
I don't think that should be a problem, as long as the client requesting
the move is informed of the new ID and URI.
>
> Several people stated that it had to change for
> accounting to work properly, although I personally don't
> agree with that opinion...
>
> 2. Requiring the server to transfer jobs to another server
> was not acceptable to a lot of people.
>
I don't know what a server is in IPP. We've got Printer, Job, and
Document. I wouldn't mind having a Server object though, along with a
Queue object. We (IBM) have considered implementing these as extensions.
> 3. What about job template options that don't map to the new
> printer object?
>
If "ipp-attribute-fidelity" is true, then the job will be rejected by the
new printer. Otherwise, you'll get status 0x0001 and the new printer will
do what it can.
> 4. What if the old server doesn't support encryption, etc.
> required by the new server?
>
Then the operation fails.
> 5. How do we pass authentication information to the new
> server?
>
The same way it was received by the old Printer.
> 6. How do we handle errors (can't transfer job to remote
> server, etc.)
>
The client is informed in the response to the Move-Job operation and/or by
notifications, polling, etc.
>I'm sure I'm missing something here.
>
>The crux of the problem is that there is a definite need for a
>"move job" operation, but implementing it fully to handle
>transferring of jobs to remote servers can be tricky and may
>not be possible for embedded implementations (personally I wonder
>if that will be an issue - I don't see embedded implementations
>supporting many of these ops that are geared towards printing
>systems)
>
I agree with you. It should always be an OPTIONAL operation.
>The proposed Redirect-Job operation sidesteps some of the harder
>issues and will allow us to partition the functionality a bit.
>That is, provide a "lightweight" redirect and a heavier Move-Job
>operation rather than a single heavy Move-Job op with several
>printer attributes describing what type of movement is supported.
>
>In other words, Redirect-Job need only support local movement,
>while Move-Job needs to handle all cases (local and remote,
>authentication, encryption, etc.) with the corresponding
>overhead.
>
I could see this argument if the Redirect-Job target were a different
Device within a Printer. But since the target is a different Printer, and
server is undefined, this operation seems poorly specified to me.
-Carl
>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products mike@easysw.com
>Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 12:01:21 EDT