My original proposal sent Friday, has the problem that once the Printer had
increased the Subscription Object's "notify-event-life" value, it couldn't
reduce it, since some client might be still using the older larger value and
not perform a Get-Notifications soon enough before an Event's (new lower)
life expired. However, this problem can be fixed by introducing two new
Subscription Object Description attributes, instead of just one:
Subscription Object attribute as before:
"notify-event-life" - the event life for Events associated with this
Subscription Object - the Printer can increase its value from the Printer's
"notify-event-life" value, but can never reduce it (because the Printer has
no concept of which clients are "listening" to a particular Subscription
Object's events.
New Subscription Object attribute:
"notify-get-interval" - the current interval in seconds between successive
events that clients should use. It can never be lower than the Printer's
"notify-event-life" which is the minimum for all Subscription Objects, but
can be lower than its Subscription Object's "notify-event-life", which the
Printer MAY have increased due to the expectation that events are unlikely
to happen any sooner than that. Thus the Printer can raise both the
Subscription Object's "notify-event-life" and "notify-get-interval", but
then subsequently lower the latter, as events start to happen again.
For example, a Subscription Object's "notify-events" have 'job-completed'
and 'job-progress' events, but the job is submitted when there was a long
job queue, say a 10 minute queue (600 second) queue. Suppose that the
administrator has configured the Printer's "notify-event-life" to the
recommended 60 seconds. The Printer would return the Subscription Object's
"notify-event-life" and "notify-get-interval" as 600 in the Job Creation
operation, instead of just 60. Then when the job starts processing, (which
could be before or after 10 minutes), the Printer reduces the Subscription
Object's "notify-get-interval" down to, say, the minimum of 15 seconds,
since page completion events are wanted.
However, the Printer still has to keep the events around for the 600
seconds, since, some hapless client might have just polled the Subscription
Object moments before the Job started processing and got the Subscription
Object's "notify-get-interval" value of 600, and so won't know to poll back
any time sooner. However, the client that sent the job would poll back
around the time that the job started processing and would get the page
completes as they occur.
Probably, a Printer that increases the Subscription Object's
"notify-get-interval" wouldn't increase it to the full amount when the Job
is likely to start, but would increase it to, say, 60%, and reduce it
further has the time arrives for the job to start, down to the minimum of
15.
A Printer that didn't want to bother with any of this complication, would
simply copy the Printer's configured "notify-event-life" to the Subscription
Object's "notify-event-life" and "notify-get-interval" and leave them
unchanged.
Tom
So here is the complete updated proposal:
1. Rename the Printer's "ippget-event-life" (integer(15:MAX)) to
"notify-event-life" to be parallel (and possibly used in the future with
some other Delivery Method).
2. Add "notify-event-life" (integer(15:MAX)) and "notify-get-interval"
(integer(15:MAX)) Subscription Description attributes to the Subscription
Object for use with IPPGET Delivery method (and possibly used in the future
with some other Delivery Method).
3. Make these Printer Description attribute and Subscription Description
attributes REQUIRED for a Printer to support, if it support the 'ippget'
Delivery Method.
4. By default, the Printer MUST set both of the Subscription Object's
"notify-event-life" and "notify-get-interval" Subscription Description
attributes from the configured value of the Printer's "notify-event-life"
attribute. However, at any time the Printer MAY set the
Subscription object's "notify-event-life" and "notify-get-interval"
Subscription Description to a higher value, if it suspects
that the events that the Subscription object are waiting for are unlikely to
happen soon. Once set to a higher value, the Printer can further increase,
but can never reduce, the Subscription Object's "notify-event-life"
attribute, but can lower the Subscription Object's "notify-get-interval"
attribute as the Event liklihood of occurring comes closer.
5. The Printer MUST return Event Notifications until the Subscription
object's "notify-event-life" expires for each Event. So if the Printer has
increased the Subscription object's "notify-event-life", then the Printer is
promising to return Event Notifications for Events for that Subscription
object for that longer life time (and can never reduce the promise, since
some client may be counting the Events not to expire for that time period).
6. As suggested by Marty, instead of returning the "notify-event-life" as an
operation attribute, return an "event-wait" (boolean) Operation attribute to
the Get-Notification (and Job Creation) Response, which indicates whether or
not the Printer is continuing Event Wait Mode. This would mirror the
"event-wait" (boolean) Operation attribute that the client supplies in the
Get-Notifications (and Job Creation) request. If the client supplies
'false' (or omits), the Printer MUST respond with 'false'. If
the client supplies 'true', the Printer MUST respond with 'true' or 'false',
depending on whether it is continuing Event Wait Mode or not, respectively.
7. For Get-Notifications response, whether or not the Printer is continuing
Event Wait Mode, the Printer always returns each Subscription object's
current "notify-event-life" and "notify-get-interval" Subscription
Description attribute values in each Event Notification Attributes Group.
The client then tries the Get-Notifications for the shortest value returned
for the "notify-get-interval" attribute and can regroup future
Get-Notifications requests, if the values returned are different for
different Subscription Objects in the same response.
8. For Job Creation responses, the Subscription Attribute Group(s) are
returned, so the Printer includes the Subscription object's current
"notify-event-life" and "notify-get-interval" Subscription Description
attributes in each group.
Comments?
Here is the ISSUE 11 and notes from the telecon:
ISSUE 11: Should the Printer return a "end-wait" (boolean) attribute,
rather than a "notify-get-interval" (integer) with the number of seconds to
try again later?
<MJ> Regarding the whole try-again time issue, I don't think the Receiver
should be sending that, and should indicate the desire to stop or not
start wait mode with a boolean or a status code. The Sender can do a
Get-Printer-Attributes to learn how long events are retained. The
Sender knows by when it must issue another Get-Notifications to avoid
the risk of losing events. If it isn't in keep-alive mode, the Sender
must take into account how long it might take to connect, so the
returning of the number of seconds to wait before trying again is
misleading.
<TH> Or we could clarify the "notify-get-interval" attribute that the
Printer is returning to be the value of the Printer's
"ippget-event-life" Printer Description attribute and the client needs to
take into the account the time to make the connection.
AGREED> That the "notify-get-interval" operation attribute returned in the
response MUST be at least as long as the value of the "ippget-event-life"
Printer Description attribute.
NOT AGREED> However, if the value is greater than the Printer's
"ippget-event-life" value, then a Notification Recipient could miss an event
if it didn't poll at the "ippget-event-life" rate. What to do?
We are still debating whether it is possible for the Printer to return a
time to next poll that is ever larger than the Event Life time? If the
Printer ever returns a larger value, the client could miss an event, unless
the Printer magically increases its Life for that (those) Subscription
object(s).
So is returning a boolean the best the Printer can ever do?
This archive was generated by hypermail 2b29 : Mon Aug 13 2001 - 02:36:45 EDT