Ah, some issues:
(1) how to indicate the last of multiple responses
(2) how to distinguish between (a) Subscription objects lease time expiring
versus (b) the Subscription Object being explicitly canceled by a client
versus (c) the Subscription Object never existing in the first place (the
client made up a bogus subscription-id or url).
For the first issue of how to indicate the normal end of Event Wait Mode
responses, Ira McDonald suggests that we define a new tag, that is like
'end-of-attributes', but is a bigger end, say 'end-of-all-parts' tag. Then
the tag can be returned on the end of the last Event Notification Attributes
Group, no matter what the status code is, and the client can avoid another
round trip to find out that the Subscription object(s) of interest is(are)
gone.
See my comments below preceded by TH>
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Monday, July 23, 2001 14:10
To: Hastings, Tom N
Cc: mjoel@netreon.com; ipp@pwg.org
Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]
"Hastings, Tom N" wrote:
> ...
> 4. Which leaves how to indicate that this is really the last response,
> i.e., that there are no more Subscription objects left that match? Marty
> Joel suggests that there be a completely separate response part with its
> own status code. The status should be the 'client-error-not-found' which
> is the status returned when there are no Subscription Objects found,
> whether this is the first Get-Notifications response or the last.
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:
(a) the lease on the Per-Printer Subscription expired (and was not renewed),
or the Per-Job Subscription was canceled after the Event Lease time expired
after the Job completed
(b) canceled by a Cancel-Subscription operation or
(c) the Subscription Object never existed.
and it doesn't cover the situation if you
do a Get-Notifications with wait=false - i.e. you are only getting a
single part, and there are events, but how do you know if you need to
ask again?
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?
How about adding a status code called
"successful-ok-subscription-expired", which will be returned by
Get-Notifications when the subscription has no more events and has
expired?
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'.
That way if a subscription is cancelled *while* a client is waiting
on more event messages, the client will see a different status code
(client-error-not-found) and can display a suitable error/warning
message, vs. seeing that a job has completed because of the
"successful-ok-subscription-expired" status?
TH> I do like having a different status though for these two different
cases.
TH> On the other hand, we have to make sure that we don't also need other
success status codes, such as
'successful-ok-ignored-or-substitutes-attributes'.
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.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 20:08:12 EDT