On 24-Nov-2009, at 15:08, Robin Collier wrote:
> 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.
No, because there is no natural order to an opaque string. Instead, you
rely on the in-order delivery semantics of XMPP and go with the most recently
received stanza. In truth, it doesn't really matter what stanza you pick,
though, as long as you pick a version you've seen.
> 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.
When you have to negotiate state between a server and application you
naturally have to resolve some issues at the application level. TANSTAAFL.
Message delivery is asynchronous, but in order. This is defined in the
RFC and non-negotiable. You might as well use it. If you have different threads
dealing with it, then synchronize them. Again, TANSTAAFL. You have to do this
stuff whether you use timestamps or opaque versions anyway or you're doing it
wrong.
> 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.
No, it takes a single additional round-trip on an <iq/> and memory in
the application of versions within the window of the iq request and response.
That is all.
More complicated? Yes. Intractable? No.
-bjc
