> From: [email protected]
> Date: Tue, 27 Oct 2009 21:41:33 -0400
> To: [email protected]
> Subject: Re: [PubSub] Timestamp on items and versioning
>
> 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 thing is, all items are implicitly required to be timestamped by the service
provider already to support delay info and item_expire. So the only extra thing
being done here is to provide that information as part of the item when it
is published. Making this part of the actual spec certainly has the added
benefit
of allowing time based retrieval of information.
>
> > 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,
Unfortunately, I am not familiar with the discussion on that part of the
protocol
so I son't know if they provide the same capabilities or not.
> 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
The only issue is when updates occur to the same persisted item within
the same base timeunit (which is what I assume you mean). Then a simple
one up on the timestamp will render a unique value for the update.
> 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
_________________________________________________________________
Lots of fantastic Windows 7 offers, in one convenient place. Get the perfect
deal for you now.
http://go.microsoft.com/?linkid=9691633
