"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