[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland dave at cridland.net
Tue Mar 11 00:06:29 UTC 2008


On Mon Mar 10 23:45:28 2008, Peter Saint-Andre wrote:
> One potential problem: this is not a nice, small, incremental  
> change.
> Now servers and clients must support:
> 
> 1. The 'sequence' attribute.
> 2. Roster pushes via message, not IQ.
> 3. Multiple items in a roster push.
> 4. Multiple items in a roster set.
> 
> The more we change, the less likely it is that clients and servers  
> will
> add this feature. Then we're back where we started.
> 
> "If it ain't broke, don't fix it."
> 
> So what's broken?
> 
> 1. Huge roster gets every time you log in. The 'sequence' stuff  
> fixes this.
> 
> What's not broken?
> 
> 2. Roster pushes via IQ.
> 3. One item per roster push.
> 4. One item per roster set.
> 
> Why are we fixing 2, 3, and 4? Just because we can? Because it is  
> more
> elegant? Or because it really solves a big problem on the network?
> 
> Unless there is a compelling need, I'd vote for changing as little  
> as
> possible.

The problem is that if you go for Joe's concept - which is certainly  
elegant - of having the roster "diff" simply sent as a bunch of  
pushes, then these - being sent as <iq/> - need to be acknowledged.  
Now, I appreciate that clients don't always do this, but the fact is  
that they should be doing so. I'm unhappy with suggesting that  
clients quietly ignore RFC 3920 because nobody cares.

So we can fix that simply by using <message/> instead of <iq/> - it's  
a pretty trivial change, and it eliminates the type='result' reply  
for clients on all pushes, so it's inarguably a performance  
improvement.

Next up, Joe introduces a problem in as much as the client can't tell  
when it's finished receiving updates, and is now receiving bona-fide  
pushes. Joe says this isn't a problem, but I'm unconvinced - client  
authors have said this is a niggle, at least, for the initial  
presence push, after all.

We can easily avoid this by having multiple items in a push - again,  
this cuts down on overhead, and so is a performance improvement.

These two are simply taking Joe's concept - the update-as-push - and  
cleaning it up, getting the protocol better.

Now... On to point 4. This isn't really needed, and it's not solving  
a big problem. But it's not a huge addition, and it does gain us a  
bit, and - perhaps most importantly - it fits neatly into this spec,  
and is too small to be independent.

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



More information about the Standards mailing list