From: [email protected]
Date: Tue, 24 Nov 2009 15:15:40 -0500
To: [email protected]
Subject: Re: [PubSub] versioning
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.
I don't think the specification should purposely make it difficult to resolve
this issue if it isn't necessary. Your statement ignores the fact that most
applications
developers will use libraries to access XMPP and not tinker at the protocol
level directly.
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.
Synchronize your synchronous requests and async messages? Is it only me
that thinks this seems unreasonable?
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.
One for each item message received that matches your results list from the
request. Of
course none of that matters, including the ver attribute (for this case) if I
am forced to
synchronize sync and async anyway, since the order of arrival will determine
which is newer.
More complicated? Yes. Intractable? No.
Painful? Yes. Reasonable? ??
-bjc
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://go.microsoft.com/?linkid=9691815
