[Standards] Proposed XMPP Extension: Roster Versioning

[Dave Cridland]

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade