[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Fri Mar 21 14:24:41 UTC 2008


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.

But why are we fixing this? In the real world, you will receive 2 or 3
roster pushes when you log in. Why are we optimizing for this? Perhaps
all this talk of optimizing is wrong -- it makes a lot more sense IMHO
to work toward satisficing. Receiving and acking 2 or 3 roster pushes is
not that big a deal. I say let's ignore that and move on to bigger problems.

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

I don't think this is a problem, but if it is then I think it's easily
solve -- include the latest sequence number in the roster result and
when you get that push you know you're up to date.

> We can easily avoid this by having multiple items in a push - again,
> this cuts down on overhead, and so is a performance improvement.

A minor one. Not worth working on IMHO.

> These two are simply taking Joe's concept - the update-as-push - and
> cleaning it up, getting the protocol better.

Needless optimization, IMHO. Sequences + pushes is good enough.

> Now... On to point 4. This isn't really needed, and it's not solving a
> big problem. But it's not a huge addition, and it does gain us a bit,
> and - perhaps most importantly - it fits neatly into this spec, and is
> too small to be independent.

See above.

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


More information about the Standards mailing list