[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 17 15:22:28 UTC 2008


Pedro Melo wrote:
> Hi,
> 
> 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 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.
> 
> Ok, I must have been missing something because if you want to fix
> something, why not just do multiple items per roster push?

Because it's never been done that way.

> 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.

But clients have never expected multiple items in a roster push.
However, that might be something clients could move to if they support
sequencing. My question is: will clients do that?

> 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-declare...
> 
> Lets not abuse the meaning of <message> just because we like their
> network properties, like we abused <presence> in the past because it
> broadcasts well.

+1.

>> 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 here.

Agreed.

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


More information about the Standards mailing list