> Date: Thu, 19 Nov 2009 14:54:49 -0600
> From: [email protected]
> To: [email protected]
> Subject: Re: [PubSub] versioning
>
> On Wed, Nov 18, 2009 at 5:20 PM, Peter Saint-Andre <[email protected]> wrote:
> > I've added text about the 'ver' attribute to XEP-0060. It's perhaps a
> > bit underspecified right now. Feedback welcome. See also:
> >
> > http://xmpp.org/extensions/tmp/xep-0060-1.13.html
>
> First up, my confusion. The title of 7.1.2.4 Item Versioning tells me
> that each item has its own version. Then I see the ver attribute on
> the <items/> element. Then I read that the version ID can be "a hash
> of the published data (e.g., of all the current items cached at the
> node)" and I understand that it's really more like Node Versioning.
>
> This expands the version concept in two directions. First, should this
> versioning then also apply to Collection Nodes? The version ID e.g.
> could be "a hash of the collection" or "a hash of the versions
> contained in the collection", take your pick. Second, should
> versioning also apply to items, as the section title implies?
>
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.
If I subscribe for notifications and then request the current items
I can end up with something like this
Reply for request for current items:
<iq type='result'
from='pubsub.shakespeare.lit'
to='[email protected]/barracks'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='princely_musings' ver='0005000'>
<item id='10'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>The Uses of This World</title>
<summary>
O, that this too too solid flesh would melt
Thaw and resolve itself into a dew!
</summary>
<link rel='alternate' type='text/html'
href='http://denmark.lit/2003/12/13/atom03'/>
<id>tag:denmark.lit,2003:entry-32396</id>
<published>2003-12-12T17:47:23Z</published>
<updated>2003-12-12T17:47:23Z</updated>
</entry>
</item>
<item id='11'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Ghostly Encounters</title>
<summary>
O all you host of heaven! O earth! what else?
And shall I couple hell? O, fie! Hold, hold, my heart;
And you, my sinews, grow not instant old,
But bear me stiffly up. Remember thee!
</summary>
<link rel='alternate' type='text/html'
href='http://denmark.lit/2003/12/13/atom03'/>
<id>tag:denmark.lit,2003:entry-32396</id>
<published>2003-12-12T23:21:34Z</published>
<updated>2003-12-12T23:21:34Z</updated>
</entry>
</item>
</items>
</pubsub>
</iq>
Event received from subscription:
<message from='pubsub.shakespeare.lit' to='[email protected]' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='princely_musings' ver='0004995'>
<item id='10'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Soliloquy</title>
<summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
</summary>
<link rel='alternate' type='text/html'
href='http://denmark.lit/2003/12/13/atom03'/>
<id>tag:denmark.lit,2003:entry-32397</id>
<published>2003-12-13T18:30:02Z</published>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</item>
</items>
</event>
</message>
And now you still cannot determine which item is the most recent, since the
version is not related directly to the item, but to any changes to the node.
The notification with the older version number can easily be the newer version
of the item, since subsequent published items and deletions may have resulted
in the higher ver attribute on the node. I don't see how you can resolve
this issue without the ver attribute or a timestamp being on the item itself.
My vote, in this case is to use a timestamp for the following reasons.
1. As I have said now on numerous occasions, every implementer is already
forced to keep a timestamp for every published item anyway to support
"6.1.7 Receiving the Last Published Item" and the node configuration attribute
"pubsub#item_expire". So this could easily be used on a per item basis since
it is implicitly required by the existing versions of the specification.
2. It can be a useful piece of information on persistent items. (in enterprise
pubsub
messaging systems, this is a very standard message attribute).
That being said, I can live with the ver attribute as well, but it does need to
be an attribute of the item.
>
> .. Stuff deleted
>
> Cheers,
> Andy
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on
Facebook.
http://go.microsoft.com/?linkid=9691816
