[PubSub] versioning

Sun Nov 22 16:29:34 CST 2009

Hi all,

2009/11/22 Robin Collier <robincollier at hotmail.com>:
>> Date: Thu, 19 Nov 2009 14:54:49 -0600
>> From: skeltoac at gmail.com
>> To: pubsub at xmpp.org
>> Subject: Re: [PubSub] versioning
>>
>> On Wed, Nov 18, 2009 at 5:20 PM, Peter Saint-Andre <stpeter at stpeter.im>
>> 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='francisco at denmark.lit/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='francisco at denmark.lit' 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.

I have ended up (at least temporary) using modtime (as defined in
http://tools.ietf.org/html/rfc2244#section-3.1.1) as ID of an item.
This will give the possibility to have a unique ID in node as well as
putting items in correct order by client easily. For example after
using xep-0202 the client can query items even by time where needed
using xep-0059.

Since this starts to have "application logic" in it, I'm not sure if
this is really needed as part of a protocol. How ever if it's often
needed feature of a pubsub system, it would be cool to find a common
way to fulfill the need. My use case is: I have presence based
delivery but I still need to query the node's existing items in some
cases.

Cheers,
--
tuomas