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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
