Hi all, 2009/11/22 Robin Collier <[email protected]>: >> 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.
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
