Hi, Peter wrote: > On 10/27/09 8:31 PM, Matthew Wild wrote: >> 2009/10/28 Brian Cully <[email protected]>: >>> On 27-Oct-2009, at 18:25, Tuomas Koski wrote: >>> >>>> 2009/10/1 Fabio Forno <[email protected]>: >>>>> so +1 for modtime >>>> we seem to have reached a overall understanding that a attribute >>>> called "stamp" could be added to the item element. Example: >>>> >>>> <item stamp='20091027225837256'> >>> It appears so, although I'm still vehemently against it. I loathe >>> timestamps and would only recommend them in the payload because they're >>> vague and error-prone.
The original idea to use the "modtime" (as defined in http://tools.ietf.org/html/rfc2244#section-3.1.1) is that it's unique. So the good point at the moment is that everyone understands the problem of the "timestamp". How ever I think we are maybe solving different problems and fulfilling different needs here. Please read below after Peters comment. >>>> On 27-Oct-2009, at 18:25, Tuomas Koski wrote: >>>> If we are going to do this, should we then also allow the usage of >>>> time stamp when requesting items from the node >>>> (http://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-requestall)? >>> We should use opaque versions, akin to rosters. This has no vagary, >>> is not as error-prone, and will scale to the foreseeable future, where >>> timestamps simply do not (what happens when you get three updates in a given >>> micro or nanosecond?) The worst case is what to do when a publish comes in >>> between requesting items and getting the result, in which case subsequent >>> requests for differences from a version will return an ever-diminishing set, >>> the most likely case being the empty set. It allows more optimizations and >>> does not rely on concepts of time which are wildly variable. >>> >> I haven't re-read the thread (though I might). However we had pretty >> much the same debate over roster versioning... what harm does it do to >> take the same approach and make the version an opaque string? Then the >> server can use a timestamp (more fool it) or something more 'smart'. > > Using the same approach for pubsub and roster versioning seems sensible. > > Peter I think Robin Collier's case (I hope I'm not wrong) is, that he needs to find a way for clients to handle the <item>s in a correct order. If this is really the case (and I have not understood anything wrong), based on a quick thought I also think that the "roster version" -way of handling this sounds like the correct way to go. What could be a good attribute name for this? My use-case then again would be more of a following: Mobile client is subscribed to a node that has a presence_based_delivery set to true. This is done not to receive "offline messages" in "uncontrolled way" when the client goes online. However, when my client logs in, I am still interested of those items published to the nodes while I was offline. I need to be able to receive them in a controlled way. I only want to have the items since I last time were logged in: in other words I need to receive all the possible items that were published since the last item I have. So I assume I could do something like this (just an idea): <iq type='get' from='[email protected]/barracks' to='pubsub.shakespeare.lit' id='items1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <items node='princely_musings'> <set xmlns='http://jabber.org/protocol/rsm'> <after>id_of_my_last_item</after> </set> </items> </pubsub> </iq> When the server will receive this it must be able to return the items in a correct order. So we come back in a point that the items must have an order in the client (what is really the current "latest" item so that it can handle items in a correct order) and in the server side (it will send the id's in correct order, for example in "pagination"-case). Do you guys think that these two problems should be discussed in separate threads or are we talking in the end about the same issue? Cheers, -- xmpp:[email protected]
