I think we are getting close to agreement. Three issues:
1. How Printer indicates that this is the last Get-Notifications response in
Event Wait Mode?
Proposal a: return a new 'successful-ok-subscription-expired' (and if there
are any unexpired Events, return them as separate Event Notification
Attributes Groups).
Proposal b: return the "notify-get-interval" (MAX) operation attribute,
i.e., with the maximum positive integer value, meaning that more events
won't "ever" happen.
(A new tag does appear to have a real disadvantage with existing IPP
operation response parsers).
If we do a, then we also need to specify the precedence, if there are other
successful ok status codes, such as
'successful-ok-ignored-or-substituted-attributes' in case the client passed
an operation attribute that the Printer didn't support (possibly an
extension in the future to a current Printer). Since the Unsupported
Attributes Group would have the unsupported attributes or values, perhaps
returning the 'successful-ok-subscription-expired' wouldn't be too much of a
problem.
2. Shouldn't we REQUIRE a Printer to return a final Get-Notifications
response (with on of the above indications: a or bb) to all waiting clients
when the Subscription object is canceled by a Cancel-Subscription operation
or because the Per-Printer Subscription Object lease expires?
3. Ok that whether the client actually disconnects on any return from
Get-Notifications is up to the client, as with all IPP operations. If the
Printer wants to, the Printer can disconnect whenever it wants to as well
(but sufficiently much after any response, that the response isn't lost).
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Tuesday, July 24, 2001 05:21
To: Hastings, Tom N
Cc: mjoel at netreon.com; ipp at pwg.org
Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]
"Hastings, Tom N" wrote:
> ...
> This will work, although it won't indicate if the subscription has run
> out or just been cancelled,
> TH> But won't it be harder for the Printer to be able to detect the
> difference when performing a Get-Notifications, to detect whether the
reason
> that the Printer can't find any Subscription Objects, is because they
were:
> ...
MS> The new status code would only be returned when there are events
(i.e.
the subscription exists), but the current response contains all that are
left and the subscription is then completed.
To clarify: Get-Notifications will return the
"successful-ok-subscription-expired" status for any Get-Notifications
request when 1) the subscription still exists, and 2) the response
contains all of the remaining events for that subscription (and no
more events can be retrieved because the subscription has expired).
If the client calls a second time, ignoring the new status code, then
it will get the client-error-not-found status code, same as before.
We just use the new status code to indicate to the client that it has
retrieved all events for the specified subscription, and can it please
stop bothering the server? :)
I prefer a new status code to a "super-end-tag"; using a new tag will
break existing implementations and will require changes to everyone's
IPP message parsing code. The only advantage is that you can look for
a byte that indicates the end of the notifications, but I don't think
caching the last status code you saw at the beginning of the last
event message is all that difficult, either...
> ...
> TH> I think that for the Event No Wait case, if the Printer doesn't return
> the "notify-get-interval" at all, that is the indication for the client
not
> to ask again. Right?
Then will the "notify-get-interval" attribute be required if the server
wants the client to ask again? Won't that break any existing
implementations?
> ...
> TH> This status code could be used with either the Event No Wait or Event
> Wait case? But it may still be hard for a Printer to distinguish that the
> Subscription Objects had expired (been canceled) from the case when the
> client supplied either a subscription-id or a url that didn't exist which
we
> currently specify as returning the 'client-error-not-found'.
MS> The logic would go something like this: Get-Notifications initially
returns client-error-not-found if the subscription object cannot be
found. If the subscription object is found, it returns successful-ok
with each intermediate set of events and
successful-ok-subscription-expired
for the terminal events. For the wait case, if the subscription is
cancelled while a Get-Notifications operation is active, a final part
with the client-error-not-found status code is returned and the
request is completed.
> ...
> TH> And how hard is it for the Printer to detect that case of clients
> waiting when a Subscription object disappears? Perhaps, the implementation
> keeps an internal list of waiting clients for each Subscription object so
> that it can tell this case when the Subscription object disappears and
> return the special 'successful-ok-subscription-expired' status code to
each
> waiting client.
Well, if a client is waiting for more parts, then the server knows
it has N clients connected to send the notifications to. If the
subscription expires with no client connected, the server has to
keep the expired subscription around for N seconds (the value of
begin-to-expire-time-interval) or until a client asks for the events.
If the client asks before the events timeout, the server sends them
to the client with the new status code. If the client doesn't ask
in time, it sees client-error-not-found.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com