[PubSub] Timestamp on items and versioning
koski.tuomas at gmail.com
Wed Oct 28 09:09:48 CDT 2009
> On 10/27/09 8:31 PM, Matthew Wild wrote:
>> 2009/10/28 Brian Cully <bcully at gmail.com>:
>>> On 27-Oct-2009, at 18:25, Tuomas Koski wrote:
>>>> 2009/10/1 Fabio Forno <fabio.forno at gmail.com>:
>>>>> 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
>>>> 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
>>> 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.
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?
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.
So I assume I could do something like this (just an idea):
from='francisco at denmark.lit/barracks'
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
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?
xmpp:tuomas at xmpp.lobstermonster.org
More information about the PubSub