[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 17 22:11:01 UTC 2008

Pedro Melo wrote:
> 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.

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?!?!"

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

More information about the Standards mailing list