[standards-jig] Re: PubSub (0060) Max_items -> Range?
mankins at media.mit.edu
Tue May 20 16:19:30 UTC 2003
Good point: in order for range requests to be meaningful the cases of
changed payloads and items sequence numbering need be addressed.
I think of the IMAP protocol which has addressed a similar problem. In
IMAP you have "mailboxes" (think nodes) and messages (think items).
If I recall correctly, in IMAP there's a UID for every message, as well as a
Sequence Number and a "UID Validity" for the entire mailbox.
If the mailbox's UID Validity changes, then clients are to disregard their
cache of uids and sequence numbers. This is IMAP's solution to the
scenario of a changed or deleted item.
A similar solution could be crafted for pubsub.
The reason I press for range functionality is because in my implementation
of pubsub I can imagine nodes containing many thousands of responses, and
while the max_items works to limit client overload, it is not optimal for
a generic partial get of node contents.
RFC 2060 (imap)
On Tue, 20 May 2003, Ralph Meijer wrote:
> You ask for the second set (#11-#20). This doesn't include 'myitem' because
> it has been updated.
> An obvious solution would be to keep track of published items since your
> initial query and compensate the requested ranges accordingly, but that assumes
> publishes, notifications and queries are handled sequentially, so that doesn't
> work either.
> By the way, this never gives you a consistent set of published items when
> publishes happen in between.
More information about the Standards