[Standards] Proposed XMPP Extension: Roster Versioning
melo at simplicidade.org
Tue Mar 11 08:42:08 UTC 2008
On Mar 11, 2008, at 12:06 AM, Dave Cridland wrote:
> 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
>> 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
>> 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
> 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
Ok, I must have been missing something because if you want to fix
something, why not just do multiple items per roster push?
The argument that diff is complex doesn't play well with me. Each
item is a replacement item, so no diff required. The usual code for a
client "foreach item update my model" will work with both.
So "abusing" message just so that you don't need to reply seems
wrong. If we really need result-less IQs then make them so: allow for
<iq type="notify"> or something and be done with it. And make it
broadcast-able to all connected resources. Yes, it needs to be in bis-
work, but then again, if you don't advertise that you want
incremental rosters, you won't get them. All is fair if you pre-
Lets not abuse the meaning of <message> just because we like their
network properties, like we abused <presence> in the past because it
> 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 lived with not knowing when the presence stream finishes, and that
was acceptable because presence is really a distributed concept so it
is impossible to know when other servers will respond.
Rosters on the other hand are purely local to the domain concepts, so
it should be easy to say when they are over.
On the other hand, I agree with Joe: our clients already have to deal
with roster pushes at any point in time, so I don't see the a problem
XMPP ID: melo at simplicidade.org
More information about the Standards