[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland dave at cridland.net
Tue Mar 18 10:35:45 UTC 2008


On Tue Mar 18 02:51:53 2008, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > It's not the bandwidth, it's the additional transmission I'm more
> > concerned with. For every <iq/> stanza, there's an addition TCP  
> data
> > packet, and therefore there'll be a further ACK - both of which  
> will
> > cost power.
> >
> > The alternative is that we quietly explain to people that they  
> needn't
> > bother replying to the <iq/> push, which I really don't like. I'm  
> pretty
> > sure that the mobile developers won't want to reply to every  
> roster
> > push, anyway.
> 
> You make a point.
> 
> 
I note you don't say if it's a good one or not. :-)

> I got my start in the Jabber community as the documentation guy. As  
> a
> result, I've always seen it as my job to document the protocols as  
> they
> are used in the community. In that sense I am a conservative, so I  
> don't
> immediately think "gosh how much can we change things?" but "how  
> little
> can we change to get our desired functionality?" In my opinion  
> that's
> one reason our community has stuck together rather than pulled apart
> (with different projects and companies defining their own  
> extensions).
> Changing core functionality in a significant way scares me because  
> the
> feedback I typically receive is that it scares our developer  
> community.
> Maybe I'm being unduly conservative here, but it seems to me that we
> legitimately might want to have roster sequencing without changing  
> the
> core behavior of roster pushes.
> 
> 
The converse problem is that for every extension which changes  
existing behaviour, rather than adding - and that's clearly the case  
here - you add a code-path. So each extension *of this type* needs to  
do as much as possible, to minimize having, at some later point in  
the future, a scenario where there are 4 or 5 extensions covering  
various optimizations surrounding rosters, and therefore 24 or 120  
different combinations.

Each of those combinations needs testing, and while it's possible for  
us to reduce them by making them mandate each other, there's a risk  
of ending up with theoretical server capabilities that we simply  
cannot test.

So yes, I agree, there's no point in making such dramatic changes as  
to put developers off, but at the same time, we don't want to build  
120 different roster behaviours. 2 is quite enough.


> To summarize the discussion so far, roster sequencing enables the  
> client
> to know if the roster has not changed (and this is what saves us the
> greatest amount of bandwidth). Beyond that I see several possible
> bundles, from smallest change from current behavior to greatest  
> change
> from current behavior...
> 
> 1. If the client provides a sequence number on login and the roster  
> has
> changed since that sequence number, the client receives one
> old-fashioned roster push (IQ-set) for each item that has been  
> added,
> modified, or removed. Subsequent roster changes are sent via
> old-fashioned roster pushes (IQ-set).
> 
> 2. If the client provides a sequence number on login and the roster  
> has
> changed since that sequence number, the client receives a "diff" --  
> that
> is, a full set of the items that have been added, modified, or  
> removed
> -- in one IQ set from the server to the client (and this diff may
> include multiple items). Subsequent roster changes are sent via
> old-fashioned roster pushes (IQ-set), with one item per push.
> 
> 
Both the above can be rolled into one extension easily - that's what  
the roster sequence validity/identifier thing I vaguely suggested was  
for.

As Joe suggested, though, the diff works fine as a set of  
old-fashioned roster-pushes.

> 3. If the client provides a sequence number on login and the roster  
> has
> changed since that sequence number, the client receives a "diff" --  
> that
> is, a full set of the items that have been added, modified, or  
> removed
> -- in one <message/> from the server to the client (and this diff  
> may
> include multiple items). Subsequent roster changes are sent via
> <message/> stanzas, which may include multiple items.
> 
> 
Well, this is two changes:

1) Sending multiple roster-pushes in one stanza.

2) Sending roster-push stanzas as <message/> instead of <iq/>.


> Is that an accurate summary? Are there other options on the table?  
> Let's
> get clear on the options so that we can figure out which one is the  
> best
> way forward.

I think this is basically accurate, but there is another way of  
looking at it - there are four extensions on the table; we can pick  
0..4 of them:

1) Maintain an indentifier for a particular roster state, such that a  
client needn't download the roster afresh unless it's changed.

2) Maintain an identifier for a particular roster state, such that a  
client may only download the outstanding pushes.

3) Allow multiple pushes.

4) Put pushes in stanzas.

Now, I think that 1 & 2 are fairly easily merged into one, but 3 & 4  
are pretty much independent.

I think they're also pretty low-hanging fruit for servers and clients  
alike - the tougher part is getting 1 and/or 2 right.

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