Hi Tom,
Well, if a subscription ID is given with a Get-Notifications request, then
only one sequence number is (optionally) needed.
I'm thinking now that instead of Get-Notifications optionally taking a
single subscription ID, maybe that should be a list, and maybe there should
be another optional list with corresponding sequence numbers.
If that is done, then the 3 possibilities are that Get-Notifications takes
subscription IDs only and no recipient uri, a recipient uri and no
subscription IDs, or both. I propose that if Get-Notifications is given a
recipient uri, then a search will be made for matching subscriptions,
regardless of whether or not any subscription IDs are given. In the event
that the recipient uri is not given, then Get-Notifications will only
return events for the given subscription IDs. Whether or not a recipient
uri is given, if corresponding sequence numbers are given with the
subscription IDs, then the starting event sequence number will apply only
to those subscription IDs. For the case where recipient uri is not given,
the optional list of corresponding sequence numbers will apply to all
subscriptions being requested.
For the case where Get-Notifications is being called with a recipient uri,
then the first call would have no subscription IDs (since if the client
knows the subscription IDs, the search for those subscriptions having that
recipient uri can be avoided). The second call would contain that
recipient uri, and may include , for each subscription of the events
returned from the first call, the subscription IDs and a list of the
corresponding next sequence numbers to receive for each. As each
subsequent call is made, if an event is returned with a subscription ID
that was previously not returned, then that subscription ID and next
sequence number will be added to the lists for subsequent calls to
Get-Notifications. The client is not required to follow this procedure,
but if followed, it lowers the number of events the printer must process
and send, and eliminates the possibility of the client receiving duplicate
events.
I realize this complicates the spec a bit, but I think it makes ippget more
versatile, and addresses Michael's excellent point of improving performance
and bandwidth.
Regards,
Marty Joel
"Hastings, Tom N" <hastings at cp10.es.xerox.com>@pwg.org on 07/27/2001
05:35:59 PM
Sent by: owner-ipp at pwg.org
To: Michael Sweet <mike at easysw.com>
cc: Marty Joel <mjoel at netreon.com>, ipp at pwg.org
Subject: RE: IPP> Duplicate ippget events
I put the following ISSUE with the IPPGET spec on the IPPFAX WG agenda for
next Wednesday, August 1, in Toronto:
ISSUE 07: For Event No Wait mode, should we add a way for the Notification
Recipient to have the Printer filter out returning Event Notifications that
the Notification Recipient has already received in order to reduce the
duplicates (that will usually happen, else events will be lost)? Or should
we just depend on most usage using Event Wait Mode, so that there aren't
duplicates? It has been suggested on the mailing list that the
Notification
Recipient could supply pairs of the "notify-sequence-number" and
"subscription-id" and the Printer would only return events with a higher
sequence number.
However, I realized that I made a mistake. Instead of needing pairs, we
could just make it work when the client is already supplying the
"subscription-id", so that he is only requesting a single Subscription
object. So the real proposal would be to add the "notify-sequence-number"
as a REQUIRED operation attribute for a Printer to support, but OPTIONAL
for
the Notification Recipient client to supply. Sounds really simple.
We could even REQUIRE the client to supply the "notify-sequence-number",
whenever it supplies the "subscription-id".
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Friday, July 27, 2001 16:57
To: Hastings, Tom N
Cc: Marty Joel; ipp at pwg.org
Subject: Re: IPP> Duplicate ippget events
"Hastings, Tom N" wrote:
> ...
> However, remember this problem is only for using Get-Notifications
> in Event No Wait mode (polling). For Event Wait mode, there aren't
> any duplicate events returned to a Notification Recipient. If we
> think that the majority of use will be with Event Wait Mode, then we
> don't need to solve the problem for Event No Wait Mode.
Even with the multipart encoding, I think there will still be a
significant number of implementations that don't implement the
event wait mode, and if we don't provide a way for clients to
specify what they've already seen then the efficiency of ippget
in this mode will be quite poor.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com