From: [email protected]
Date: Tue, 24 Nov 2009 13:37:30 -0500
To: [email protected]
Subject: Re: [PubSub] versioning
On 22-Nov-2009, at 15:51, Robin Collier wrote:Now that the timestamp vs.
versioning has resulted in node level
versioning, it fails to address one of the original problems I was
attempting to address with the timestamp. Order of operations
between a retrieve items and a notification. This cannot be
determined with the current proposal of a ver attribute on the
list of items.
This is, indeed a complication. One I raised early on in my championing
of `ver' on this list. It does have a solution, but it makes clients more
complicated (then again, at least they'll be correct, where timestamps do not
necessarily have this appeal).
Basically, you request items, and you get an event in the same window.
You do not know which is the most recent version. To solve this problem you
have to issue another get-items request with the version most recently received
by your application (time-wise). If the result comes back with the a version
that you've seen (or the empty set) then you are now up-to-date in your
application. If it comes back with a new version, you should also have received
the intermediate events leading up to (and perhaps past) that version[1], and
you are now up-to-date in your application. So you add an extra round-trip in
the edge cases, which does suck, but is tractable, and overall I think
versioning buys more than it loses.
I would assume that you are going to request with the latest version
by virtue of the natural order of the version string, not by time.
-bjc
[1] If you're thinking this just sends you back to step one, you're wrong. XMPP
has in-order delivery semantics, and with that property you can simply note
that at some point in time you saw the version in the get-items result, and
even if you've seen events past that, you know that you're caught up, because
by definition they were sent after your result was computed, so your most
recent event is the current state of pubsub.
I disagree. XMPP semantics aside, the problem is that you are trying to
resolve this
issue at the application level. At that level, the order of XMPP stanzas
between synchronous
requests and asynchronous messages will not likely be known. Most (all)
applications will
have completely different threads of execution for handling both cases.
Even if that was not an issue, catching up could be a serious pain on a busy
node with
many of the items showing up in messages while trying to resolve the original
retrieved
list.
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail
you.
http://go.microsoft.com/?linkid=9691817
