[Standards] Proposed XMPP Extension: Roster Versioning
stpeter at stpeter.im
Mon Mar 10 21:55:33 UTC 2008
Dave Cridland wrote:
> 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.
Agreed, I think that's what the server returns in this case.
>> - 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
Joe's suggestion works for me here, but I confess that I don't
understand the concept of a sequence validity marker.
>> - 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
I pondered that for a while before settling on the diff. My main concern
with the roster-push-only model is that there could be an awful lot of
roster pushes, each of which (1) has TCP and IQ overhead associated with
it and (2) needs to be acked by the client per RFC 3920 (but in practice
not all clients do this). But if there would be lots of roster pushes
(where "lots" is defined by that smart server to which your dumb client
is connected) then the server could send you the complete roster, right?
> That's quite a neat design. It eliminates the diff attribute.
Yes, I think it would.
>> Then, all I have to do is store my current roster, and apply diffs to
>> it in exactly one way.
> Yes, I like this.
It's definitely worth pondering some more.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards