[PubSub] Timestamp on items and versioning

Tuomas Koski koski.tuomas at gmail.com
Wed Oct 28 09:09:48 CDT 2009


Hi,

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
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?

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):

<iq type='get'
 from='francisco at denmark.lit/barracks'
 to='pubsub.shakespeare.lit'
 id='items1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
   <items node='princely_musings'>
    <set xmlns='http://jabber.org/protocol/rsm'>
     <after>id_of_my_last_item</after>
    </set>
   </items>
  </pubsub>
</iq>

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
"pagination"-case).

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?


Cheers,
--
xmpp:tuomas at xmpp.lobstermonster.org


More information about the PubSub mailing list