IPP Mail Archive: RE: IPP> Object Persistence [ISSUE 03 - Jo

RE: IPP> Object Persistence [ISSUE 03 - Job Persistence]

From: Marty Joel (mjoel@netreon.com)
Date: Mon Aug 06 2001 - 18:47:21 EDT

  • Next message: McDonald, Ira: "RE: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing o utbound channel connection only]"

    Hi Tom,

    Good argument -- you have my OK.

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 08/06/2001 12:50:47 PM

    To: Mike Sweet <mike@easysw.com>, Marty Joel <mjoel@netreon.com>
    cc: ipp@pwg.org

    Subject: RE: IPP> Object Persistence [ISSUE 03 - Job Persistence]

    I support Michael Sweet's and Ira McDonald's point that if a Printer
    supports the IPPGET Delivery Method, then that Printer is required to keep
    Jobs in either the Retention Phase or the Job History Phase for at least
    the
    amount of time that the Printer keeps Events after they occur. Then the
    Notification Recipient can look at the event and then get any Job
    attributes
    from the Job object using the Get-Job-Attributes operation (as long as the
    Event Time Out hasn't occurred).

    While the Subscribing Client could put the attributes that the Notification
    Recipient might be interested in into the Subscription's
    "notify-attributes", "notify-attributes" is an OPTIONAL feature for the
    Printer to support. Worse, Subscribing Client might not know what
    attributes the Notification Recipient might be interested in when the
    Notification Recipient sees the event. It would be really bad if the
    client
    had to put all the job attributes in the Subscription's "notify-attributes"
    attribute just to make sure that they were there for the Notification
    Recipient when the event occurred.

    As a real world example, suppose you had an accounting application that was
    known to the system and so could create a Per-Printer Subscription object
    for a long lease (or indefinitely). It would be unfortunate, if the
    accounting application had to put all of the Job's attributes into the
    Subscription object's "notify-attributes" attribute. It is much simpler
    for
    the accounting application to be able to harvest whatever Job attributes is
    wants during the event life time after the Job completes using a
    Get-Job-Attributes operation. Also that accounting application won't be
    depending on the Printer to implement the OPTIONAL "notify-attributes"
    Subscription Template attribute.

    So OK to REQUIRE that an implementation that supports IPP Notification
    using
    the IPPGET Delivery Method, has to keep jobs so they can be queried using
    Get-Job-Attributes (i.e., keep them in Retained or Job History Phase - see
    RFC2911 section 4.3.7.2) after they complete (complete, abort, or cancel)
    for at least as long a time as the Printer's Event Life Time?

    Tom

    -----Original Message-----
    From: Mike Sweet [mailto:mike@easysw.com]
    Sent: Sunday, August 05, 2001 19:00
    To: Marty Joel
    Cc: ipp@pwg.org
    Subject: Re: IPP> Object Persistence [ISSUE 03 - Job Persistence]

    Marty Joel wrote:
    > Micheal Sweet wrote:
    >
    >
    >>This prevents you from gathering the job-media-sheets-completed
    >>attribute after a notification that a job is complete, for example.
    >>I *thought* that we wanted a client to be able to query a job object
    >>after receiving a notification, and that job object should only
    >>disappear after all events referencing the job object expire.
    >>
    >
    > Couldn't this be handled by putting job-media-sheets-completed in
    > notify-attributes?

    Yes, however if you have subscribed for progress events, you may
    not want all of the attributes at once (i.e. basic stuff for the
    progress and then grab everything for the job-completed event)

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



    This archive was generated by hypermail 2b29 : Mon Aug 06 2001 - 18:50:32 EDT