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?!?!"
smime.p7s
Description: S/MIME Cryptographic Signature
