[Standards] Proposed XMPP Extension: Roster Versioning
stpeter at stpeter.im
Mon Mar 10 22:14:42 UTC 2008
Peter Saint-Andre wrote:
> 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:
>>> - 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.
OK, I pondered it some more.
I think the roster-push-only design is superior, because clients already
know how to handle roster pushes, whereas they don't know how to handle
roster diffs. If we can define roster sequencing in such a way that it
uses only the primitives that clients already understand (full roster
and roster push), then clients will be more likely to implement roster
sequencing. And that's a Good Thing.
Now we just need to describe a good rule of thumb for servers to follow
in deciding whether to send the full roster or a series of roster pushes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards