[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland dave at cridland.net
Wed Mar 5 09:10:08 UTC 2008

On Tue Mar  4 23:48:53 2008, Pedro Melo wrote:
> On Mar 4, 2008, at 10:27 PM, Dave Cridland wrote:
>> "The value of the 'version' attribute is an integer value which is  
>>  increased with any change to the roster, whether or not the  
>> client  supports this extension. In particular, the 'version'  
>> attribute  contained in roster pushes (see Section 2.5) MUST be  
>> unique."
> +1. I can't see any reason for the spec to require more than a   
> increasing version number.
The key phrase "strictly increasing sequence number" needs to be  
present somewhere, to keep mathematicians happy. ("Monotonically  
increasing" varies in its meaning in different parts of the world,  
bizarrely, so there's a phrase to avoid).

>> Section 2.2:
>> Include some text saying that clients can set version to 0 if they  
>>  have no roster cached with a version - otherwise there's no  
>> bootstrap.
> Or omit  the version maybe?
No, omitting the version means "I'd like the full roster and I do not  
understand versions".

>> Section 2.4 needs to include a method for servers to indicate   
>> whether this is an update, or a complete replacement.
> Why? A complete replacement is just a full set of updates. The  
> final  XML would be equivalent. From the client perspective, he  
> would  replace all the cached local entries.
No, it isn't. There's that "removed" value for subscription. In the  
case where a full update is needed, it's quite likely that one of the  
reasons is because the server can't remember all (or any) deletions.

If a full update looks the same as a diff, then a client cannot know  
to remove otherwise undead entries.

>> Finally, I'd include an assertion for roster sets - so that a   
>> client can perform actions such as a "set if not changed since".   
>> Dead easy for servers, I think.
> I don't follow what this is. Can you elaborate with a use case?

It is, as PSA suggested, just a convenient place to put a potentially  
cool feature. I'm far from wed to it, but it'd be nice to at least  
keep it in mind.

But, let's say that you had a bot which processed all entries in it's  
roster. Let's further complicate things by having multiple instances  
of the bot, because it's a CPU heavy bot. Now, it can do work by:

1) Finding all entries not in the "Processed" group.
2) Doing a conditional modify of the roster, placing an entry into a  
"Processing" group.
3) If that succeeds, process, then place it (unconditionally) into  
the "Processed" group.
4) GOTO 1 (Gotta love that BASIC).

There's far simpler use-cases, such as adding a group. (The client  
cannot add a group, it can merely change groups, so to add one  
without potentially removing a newly added one, it must ensure  
nothing else has changed the roster since it last operated.)

For both these use-cases, it would imply that we could specify this  
slightly tighter, and insist that each roster entry has a sequence  
value visible to the client. I can't think of a sane server  
implementation that wouldn't do this anyway.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list