-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/28/09 8:50 AM, Robin Collier wrote: > > >> Date: Wed, 28 Oct 2009 15:09:48 +0100 >> From: [email protected] >> To: [email protected] >> Subject: Re: [PubSub] Timestamp on items and versioning >> >> 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? > > Although I am not familiar with the discussion on roster versioning, it > looks like what you are saying is correct. > > The point I raised in my last message though was that the timestamping > is already required for any implementeing service, and I guess I fail to > see > why it cannot server both purposes. As it is, there seems to be several > suggestions (like your own) that would required the timestamp on the item.
The idea behind roster versioning is that a server *could* use timestamps but there enough problems with timestamps that it's better to say that the version ID is an opaque identifier. We had a long thread about this w.r.t. roster versioning so I'd rather not repeat that here. :) 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/ iEYEARECAAYFAkroZ5UACgkQNL8k5A2w/vzq1ACfUB4LK8vhsUKemLc6ENURzOvd zngAoOGiA93Og1CzZ6A8ASD8yaxTDPZ8 =aSoJ -----END PGP SIGNATURE-----
