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.
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 realize I lost this argument a long time ago, but I wanted to
restate the case, because I still feel very strongly about this issue.
Timestamps suck in every way except advisory. Encoding them in the
protocol is a mistake.
-bjc
