[Standards] Proposed XMPP Extension: Roster Versioning
dave at cridland.net
Mon Mar 10 20:52:45 UTC 2008
On Mon Mar 10 20:32:17 2008, Dave Cridland wrote:
> On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
>> - 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.
But then I thought a little harder whilst finishing cooking.
1) How does the client know that it's got all the updates?
2) Doesn't this mean that every roster push has to be acknowledged?
Doesn't this increase the transmissions required from a client? (Note
that the client cannot pipeline them all into the same TCP packet,
because of (1) - otherwise, it'd presumably compress well).
So I think yes - easiest to get rapid deployment, but no - it's much
harder to get a quality implementation.
You can take our existing "diff" format and push each item through
your internal roster push handling, incidentally. Not much
refectoring involved, although certainly more than your design, but
you get a clean protocol at the end of it.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards