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.
-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.
