[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre 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:

<snip/>

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080310/fd01915a/attachment.bin>


More information about the Standards mailing list