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 - 15:54:31 EDT