[Standards] Proposed XMPP Extension: Roster Versioning

juha.p.hartikainen at nokia.com juha.p.hartikainen at nokia.com
Thu Mar 6 08:29:13 UTC 2008


Hi!

Comments below marked as jph:

Cheer's
<Juha> 

>-----Original Message-----
>From: standards-bounces at xmpp.org 
>[mailto:standards-bounces at xmpp.org] On Behalf Of ext Peter Saint-Andre
>Sent: 06 March, 2008 06:36
>To: XMPP Extension Discussion List
>Subject: Re: [Standards] Proposed XMPP Extension: Roster Versioning
>
>juha.p.hartikainen at nokia.com wrote:
>> 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 bill at shakespeare.lit 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?
>
>I suppose that's up to the implementation. But if the server 
>doesn't remember back to the version cached by the client then 
>we need to specify the server's behavior (probably it would 
>return the latest version of the entire roster, just as it does today).
>
	jph: Yes, the "server's behavior" must be define. 
	I agree "probably it would >return the latest version of 
	the entire roster, just as it does today" is excellent and
simplest approach
	and it will work.
>
>Peter
>
>--
>Peter Saint-Andre
>https://stpeter.im/
>
>



More information about the Standards mailing list