From: [email protected]
Date: Tue, 24 Nov 2009 20:31:39 -0500
To: [email protected]
Subject: Re: [PubSub] versioning
On 24-Nov-2009, at 19:30, Robin Collier wrote: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.
If you want to invoke "libraries" then the issue becomes simpler. This
semantic is easy to encapsulate within a library and developers who use that
library don't need to care /at all/.
Synchronize your synchronous requests and async messages? Is it only methat
thinks this seems unreasonable?
Welcome to XMPP, the asynchronous protocol with a subset of synchronous
delivery semantics. There's no avoiding the fact that while your synchronous
request is being processed an asynchronous event will be delivered. If you
think this only occurs within pubsub you are sorely mistaken.
Painful? Yes. Reasonable? ?? And timestamps do not solve even one of the
issues you've brought up except in some completely untested personal trial of
what you believe should work in absence of any other evidence.
If the item is timestamped, it determines order so no round trip to the server
is necessary. Of course a version attribute with a natural order on the item
would do this as well. How does this not solve this problem? This of course
assumes that the timestamp is not the same for two different versions of the
same item (as I have said would be required before).
On a different note, your mail tool seems to make it difficult to do replies
that
actually mark the existing text. I have to manually indent for the replies,
which
I haven't had an issue with on any elses messages. What tool are you using?
-bjc
_________________________________________________________________
Ready. Set. Get a great deal on Windows 7. See fantastic deals on Windows 7 now
http://go.microsoft.com/?linkid=9691818
