[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Tue Mar 18 02:51:53 UTC 2008


Dave Cridland wrote:
> On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote:
>>
>> But that's neither here nor there. The question is whether:
>>
>> (1) acking an occasional roster push from the server to the client
>> (where BTW the server *does* know your full JID) is a serious problem
>> that we need to solve because it wastes large amounts of bandwidth
>>
>>
> 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.

>> or
>>
>> (2) sending roster pushes via <message/> is a pretty optimization that
>> is more elegant than what we developed in 1999, but it fundamentally
>> unnecessary
>>
>> I think (2) obtains. Therefore I think it's just fine to keep IQs for
>> roster pushes. If it ain't broke, don't fix it.
> 
> Nothing here is necessary; the question is whether we can, and should,
> do it.
> 
> Remember, rosters are not broken right now - they work just fine. So, if
> we're going to change things, we may as well consider how much we can
> change things, rather than how little.

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.

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.

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.

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.

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/20080317/c50c3e92/attachment.bin>


More information about the Standards mailing list