[PubSub] Timestamp on items and versioning
stpeter at stpeter.im
Wed Oct 28 10:45:31 CDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 10/28/09 8:09 AM, Tuomas Koski wrote:
> Peter wrote:
>> 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?
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='francisco at denmark.lit/barracks'
> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> <items node='princely_musings'>
> <set xmlns='http://jabber.org/protocol/rsm'>
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the PubSub