[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 17 22:53:41 UTC 2008


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

True. I contend that not receiving the main roster on login is the major
savings. If a few roster pushes dribble in after you login, it's no big
deal in the grand scheme of things (after all, how many people log in
with multiple clients and experience multiple roster changes while they
are offline with a given client?).

> The current method of a
> single item per push would waste a bit in the IQ replies. 

A bit, yes. But we don't have to save every last little byte. Let's
differentiate between what's nice and what's necessary.

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

Don't get me wrong: I'm not deeply opposed to multiple items in a roster
push. If we bundle that feature with roster synchronization then we'll
probably be OK. I just wanted to make sure we performed a sanity check
with our wonderful developer community before we moved ahead. :)

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


More information about the Standards mailing list