Time to wade in with my comment :) Tuomas's point about specifically requesting new posts on login rather than expecting the node to start throwing back the missed posts while we were offline is actually useful, it means that you can delay the possible flood of posts. So for example if a user is subscribed to 20 nodes in the manner described when he logs in he can get the latest posts in a "controlled" manner (thus avoiding the normal presence style flood on login). At least thats my thoughts on what he said.
Cheers Kirk 2009/10/28 Peter Saint-Andre <[email protected]> > -----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----- >
