Hi!
Sorry missed to say that user might use several client, which caches the
roster.
Cheer's
<Juha>
>-----Original Message-----
>From: Hartikainen Juha.P (Nokia-S&S/Oulu)
>Sent: 05 March, 2008 23:37
>To: 'XMPP Extension Discussion List'
>Subject: RE: [Standards] Proposed XMPP Extension: Roster Versioning
>
>Hi!
>
>I readed the latest version 0.0.3 and I'm little bit confused
>of statement (or I have missed something):
>
>--- clip ---
>The "roster diff" can be understood as follows:
>
> 1. Imagine that the client had an active presence session
>for the entire time between its cached roster version (in this
>case, 305) and the new roster version (317).
> 2. During that time, the client would have received roster
>pushes related to roster versions 306, 307, 308, 309, 310,
>311, 312, 313, 314, 315, 316, and 317.
> 3. However, some of those roster pushes might have
>contained intermediate updates to the same roster item (e.g.,
>changes in the subscription state for [EMAIL PROTECTED]
>from "none" to "to" and from "to" to "both").
> 4. The roster result would not include all of the
>intermediate steps, only the final result of all changes
>applied while the client was in fact offline.
>
>--- clip ---
>
>Q: How many roster version have to server remember? In the xep
>0.0.3 there is clear spec for client site implementation, but
>server site is missing "server site requirements". If I keep
>changing the roster add, remove few times ("on/off
>relationship") --> how many roster versions have to be server
>must remember backwads 1...n?
>
>Cheer's
><Juha>
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of ext Alexander Gnauck
>>Sent: 05 March, 2008 22:45
>>To: [email protected]
>>Subject: Re: [Standards] Proposed XMPP Extension: Roster Versioning
>>
>>Peter Saint-Andre schrieb:
>>> Here is revised text:
>>>
>>> The value of the 'version' attribute SHOULD be a non-negative
>>> integer representing a strictly increasing sequence number that
>>> is increased with any change to the roster (whether or not the
>>> client supports this extension) but MAY be a unique
>identifer that
>>> is opaque to the client but understood by the server. In
>any case,
>>> the 'version' attribute contained in roster pushes MUST
>be unique.
>>
>>great, +1
>>
>>> Can we stop painting this bike shed and move on? :)
>>
>>yes
>>
>>Alex
>>
>>
