Hi, That really sounds great to have there, willing to give one point for this one here and now.
The following would require (by me) at least the option to allow publiser to set version number for item, and to get the error if ItemId,'Ver' is not Uniq. "The value of the 'ver' attribute MUST be generated by the service, not accepted by the service in the published item." This would make the trick here, just as the timestamp would do, and really cannot see the big difference between 'ver' or 'timestamp' there now, as both are planned to be generated by Service. Generation by service would not guarantee that into the level where I can as subscriber swap from one feed source to other similar one (namely from server1 to server2 for node "my/interest") with subscribing only the items after the 'ver=xxx"' The very same comes to problem to solve the case "should I update this item from secondary feed or not", being same feed subscribed from two servers. With service creating the 'Ver' or Timestamps, the subscriber can't know which update is the lates ones, when must believe it to be the one received last. (timestamp can go close to it, but due to different processing times and laod that cannot trusted, and very same feed should be able to set up from cracth with the log file/log DB at any time anyway) With stamp set by publisher, if publisher does in right, the two or more feed for the same thing can be used and so the subscription quality and failover capability ensured. >From publisher point of view, two identical feed is impossible to create. So Server1 and Server2 cannot hold _exactly_ the same feed when it comes to ItemID, 'Ver' pairs. (which is requirement to algorithm above) As well, in the service level (may be later in XEP-0060) the circular pub/sub nodes subscribing each others, offering the same feed for their subscriber can be created (homeworks :)) Succesfull need of use for 'ver' described above would require the 'retract' messages to hold the same 'ver', and service to keep the retracted items as answers for those who will subscribe the items after 'ver'=xxx, the time or number of the retracts should be configuratable through the service. So, really, my 2 cents. I can't find what is to be solved by this 'Ver' over the timestamps, there might be som just not getting it in my mind now. br, Ville Varis (publish-subscribe since 1999) On Thu, Nov 19, 2009 at 1:20 AM, 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 > > ###### > > 7.1.2.4 Item Versioning > > If configured to do so (via the "pubsub#versioning" configuration > field), the service can include the "version" of the published data when > it generates notifications. > > Example 105. Service Notifies Subscribers > > <message from='pubsub.shakespeare.lit' to='[email protected]' > id='foo'> > <event xmlns='http://jabber.org/protocol/pubsub#event'> > <items node='princely_musings' > ver='some-version-string'> > <item id='ae890ac52d0df67ed7cfdf51b644e901' > publisher='[email protected]'> > [ ... ENTRY ... ] > </item> > </items> > </event> > </message> > > > Definition: The 'ver' attribute is a string that identifies a particular > version of the data published at a node. The value MUST be generated > only by the server and MUST be treated by the client as opaque. The > server can use any appropriate method for generating the version ID, > such as a hash of the published data (e.g., of all the current items > cached at the node) or a strictly-increasing sequence number. > > Note: The value of the 'ver' attribute is conceptually equivalent to the > 'ver' attribute from Roster Sequencing [22]. > > The value of the 'ver' attribute MUST be generated by the service, not > accepted by the service in the published item. > > The combination of the ItemID and 'ver' MUST be unique, such that a > subsequent publish with the same ItemID MUST have a different value of > the 'ver' attribute than the earlier published item. > > ###### > > 6.5.9 Requesting All Items Since a Given Version > > The subscriber can request all items published since a particular > version of the published data by specifying the Node ID and 'ver' > attribute (about which see Item Versioning). > > Example 87. Subscriber requests items since a given version > > <iq type='get' > from='[email protected]/barracks' > to='pubsub.shakespeare.lit' > id='items3'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > <items node='princely_musings' > ver='some-version-string'/> > </pubsub> > </iq> > > > The service would then return all the items published since that version > of the data published at the node. > > ###### > > > <field var='pubsub#versioning' > type='boolean' > label='Provide versioning information about published items'> > <value>0</value> > </field> > > ###### > > <xs:element name='items'> > <xs:complexType> > <xs:choice> > <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/> > <xs:element ref='retract' minOccurs='0' maxOccurs='unbounded'/> > </xs:choice> > <xs:attribute name='node' type='xs:string' use='required'/> > <xs:attribute name='ver' type='xs:string' use='optional'/> > </xs:complexType> > </xs:element> > > <xs:element name='item'> > <xs:complexType> > <xs:choice minOccurs='0'> > <xs:any namespace='##other'/> > </xs:choice> > <xs:attribute name='id' type='xs:string' use='optional'/> > <xs:attribute name='node' type='xs:string' use='optional'/> > <xs:attribute name='publisher' type='xs:string' use='optional'/> > <xs:attribute name='ver' type='xs:string' use='optional'/> > </xs:complexType> > </xs:element> > > ###### > >
