[Standards] Proposed XMPP Extension: Roster Versioning

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


Hi,

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.

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





More information about the Standards mailing list