> Date: Wed, 25 Nov 2009 16:06:38 +0000
> From: [email protected]
> To: [email protected]
> Subject: Re: [PubSub] versioning
>
> On Wed Nov 25 14:52:38 2009, Robin Collier wrote:
> > 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).
> >
> >
> The only possible reason to want a timestamp is if you want to
> synchronize ordering between two independent sources, and don't mind
> the risks that entails.
I don't know if you have followed the entire thread, but independent
sources don't matter, since the ability to know the order only applies
to a single item in a persistent node, not the ordering of all items published
to the node. This is needed, IMHO, since a persisted item can be
overwritten and said item can be retrieved by both synchronous and
asynchronous means, leaving no current way to know if they are the
same item or not (in a persistent node).
>
> Otherwise, there's nothing gained by a timestamp - including an
> ACAP-style modtime - that isn't gained by either a strictly
> increasing integer, or an opaque string which the server can do
> something useful with.
>
You are correct in that it doesn't have to be a timestamp, as I pointed
out anything that indicates order will do. I suggested a timestamp
since I do believe timestamps are a generally useful piece of information
in persisted pubsub data, and it is already required for any implementation
to associate such a stamp with each published item because of other
requirements currently in the spec. The timestamping is already being
done by every implementation, I am only suggesting adding it to the
schema for <item> so it will easily resolve the issue with the item
changing.
> This is not to say that timestamps have no place in PubSub, but
> whether or not they're the right solution depends entirely on your
> goals.
>
> I'm not clear on what anyone's goals are, currently, but I would note
> that if you want to - for example - try to avoid PEP events that
> you've probably received already, then a timestamp in the presence
> would seem like a sensible option. Whereas if you want atomicity in a
> pubsub event stream, such that events are delivered once and once
> only over an unreliable network, then it's probably not the tool
> you're looking for. (Or it might be, but only if the timestamps are
> ACAP-style modtimes, which are designed to satisfy both - with some
> risk involved as usual).
>
> > 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?
>
> He's using Apple Mail 2. Sadly not doing format=flowed, butthe
> text/plain part is reasonable. But yes, you're highlighting the
> reason why people suggest avoiding HTML messages on mailing lists.
>
> Dave.
> --
> Dave Cridland - mailto:[email protected] - xmpp:[email protected]
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on
Facebook.
http://go.microsoft.com/?linkid=9691816
