> Date: Thu, 3 Dec 2009 13:23:28 -0700
> From: [email protected]
> To: [email protected]
> Subject: Re: [PubSub] finishing up 1.13
>
> On 12/3/09 12:54 PM, Robin Collier wrote:
> >
> >
> >> Date: Thu, 3 Dec 2009 11:56:30 -0700
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: [PubSub] finishing up 1.13
> >>
> >> OK folks, it's time to push version 1.13 of XEP-0060 out the door. My
> >> main question is: do we have consensus on the versioning stuff? If not
> >> (and if we can't gain consensus soon), then I would vote to remove it so
> >> that we can publish 1.13.
> >>
> >
> > I am sure it comes as no surprise, but I believe 'ver' values need to be
> > ordered
>
> In roster versioning (XEP-0237), we said only that the 'ver' needs to be
> unique, leaving it up to the implementation whether it will make the
> 'ver' a strictly-increasing sequence number (and I think that's the
> consensus for pubsub, as well). It's not clear to me why pubsub 'ver'
> needs to be ordered. Could you please recap your argument for why *all*
> pubsub implementations (not just your implementation) MUST enforce ordering?
>
Copied from an earlier post:
-----------
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.
--------------
I realize there are a few new additions with regard to the ver on an item, but
it
does not help in resolving this issue either since it is only on notifications,
and
cannot determine order.
I think this would be a fairly typical case where upon startup, the application
will register for notifications and then get the current items in the node to
get
the current 'state of affairs' of the node. Whether it is all items or those
beyond
a certain version doesn't matter, the problem is that you have a chicken and
egg problem at the application level. I have two notification with the same id
but you don't know which one is more recent.
Sure I can retrieve the item again, but you have to hope that you don't get
another notification to start the cycle all over again.
> > and present in the request for items on a per item basis
>
> A request for items is (typically) a request for 1+ items, and that's
> covered by a new section in the spec. A client is free to include 'ver'
> on the request, but is not required to do so. Are you suggesting that
> the spec makes this a MUST? Do you also think that a request for a
> particular item MUST include the 'ver'?
>
> > to resolve
> > the issue with synch and async retrieval of the same item at the application
> > level. This would then resolve more use cases than the opaque id.
>
> So implement it that way in your system. I still don't see why this
> needs to be a MUST for all implementations.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://go.microsoft.com/?linkid=9691815
