[Standards] Proposed XMPP Extension: Roster Versioning

[Dave Cridland]

On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
> In section 2.4, would it be easier to implement in existing clients  
> if:
> 
> - The response to the iq/get with version 0 was a full roster, in  
> the  existing format, with the addition of the current version  
> number

I think it is, isn't it? The spec actually allows a diff from  
nothing, but in this instance, it doesn't matter whether it's  
technically a "diff" or not, since you'll get full items for  
everything that's changed, and everything will have done.


> - The response to iq/get could always be a full roster, if the  
> server  got confused in any way, or know that it would be more  
> efficient to  just start from scratch

This is (or should be) the case.


> - If the roster has been completely deleted, the response would be   
> empty, but have version 0

I've a diff for specifying a sequence validity, which changes when  
the roster is effectively a new one. (So it'll change if the account  
is deleted and recreated, and it'll change if the server is restored  
from backup, and it'll change if the server simply can't really be  
bothered to use any kind of useful sequence, and instead changes it  
on every change).


> - The response to iq/get would otherwise be empty, except for the  
> new  version number
> - All changes would be sent to the client as roster pushes after  
> the  iq/response, ordered such that the last one had the current  
> version  number
> 
> 
That's quite a neat design. It eliminates the diff attribute.


> Then, all I have to do is store my current roster, and apply diffs  
> to  it in exactly one way.
> 
> 
Yes, I like this.

Dave.
-- 
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