IPP Mail Archive: Re: IPP> OPS - Redirect-Job (a ka Move-Jo

IPP Mail Archive: Re: IPP> OPS - Redirect-Job (a ka Move-Jo

Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPrinter A dmin (Set2) spec

From: Michael Sweet (mike@easysw.com)
Date: Tue Jul 11 2000 - 07:47:24 EDT

  • Next message: Michael Sweet: "Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPrinter A dmin (Set2) spec"

    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.

           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.

        3. What about job template options that don't map to the new
           printer object?

        4. What if the old server doesn't support encryption, etc.
           required by the new server?

        5. How do we pass authentication information to the new
           server?

        6. How do we handle errors (can't transfer job to remote
           server, 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)

    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.

    -- 
    ______________________________________________________________________
    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 - 07:57:05 EDT