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