[Standards] Proposed XMPP Extension: Roster Versioning

Pedro Melo melo at simplicidade.org
Mon Mar 17 22:38:06 UTC 2008


On Mar 17, 2008, at 10:11 PM, Peter Saint-Andre wrote:
> Pedro Melo wrote:
>> On Mar 17, 2008, at 3:22 PM, Peter Saint-Andre wrote:
>>> Pedro Melo wrote:
>>>> 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?
>> Yes. Basically if I'm a client and I'm telling the server that yes, I
>> support sequencing and I want to use it, the server is OK to change
>> previous rules if they are specified in the new XEP.
> Yes, I know that client developers *could* add this support, but my
> question is: *will* they really do so or will they see this spec  
> and say
> "well this roster sequencing stuff looks nice but &@#$&?^!@ I need to
> modify my roster handling code and I haven't touched that in 3 years,
> what the heck is the XSF thinking?!?!"

Yes, I understand that.

The whole point about this was saving bandwidth. The current method  
of a single item per push would waste a bit in the IQ replies. The  
alternatives suggested where re-using messages to deliver roster  
pushes, or ignore the IQ replies with a new IQ type "fire-and- 
forget" (not the final type of course :) ) or bundle up multiple  
roster items in a single push. I might have missed another approach...

Of all this, I think the multiple items per push is the least  
intrusive. But if even that is a problem, we could always make it an  
option: when we tell the server that we want to use roster sync, tell  
him that we support multiple items per push also.

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Standards mailing list