-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/09 8:09 AM, Tuomas Koski wrote: > 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?
We could call it 'ver' just as for rosters. > 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. Joe Hildebrand and I had this usecase in mind when we updated XEP-0256 so that you could include your last unavailable time in initial presence. A smart pubsub service could use that information to send you all the items that were published since you were last online. I realize that this would not be completely precise (clock skew etc.), but it would probably be good enough for most use cases. > 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> If the pubsub service is doing presence-based delivery, why should I be forced to send a get-items request? Ideally the pubsub service would be able to send me what I want based on my presence information. However, if you want more precision then we could do something like what you sketch above. > 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? I think that your use case is an extension of the versioning concept. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkroZxsACgkQNL8k5A2w/vxYzgCfYQDKudgrh8B81i9wjLuS+7Pq ytUAoNqTERBJtE/ZObAnsUiBqyglLxGg =e8Mh -----END PGP SIGNATURE-----
