[Standards] Proposed XMPP Extension: Roster Versioning
dave at cridland.net
Mon Mar 10 20:32:17 UTC 2008
On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
> In section 2.4, would it be easier to implement in existing clients
> - The response to the iq/get with version 0 was a full roster, in
> the existing format, with the addition of the current version
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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards