Pedro Melo wrote: > Hi, > > 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? > So "abusing" message just so that you don't need to reply seems wrong. > If we really need result-less IQs then make them so: allow for <iq > type="notify"> or something and be done with it. And make it > broadcast-able to all connected resources. Yes, it needs to be in > bis-work, but then again, if you don't advertise that you want > incremental rosters, you won't get them. All is fair if you pre-declare... > > Lets not abuse the meaning of <message> just because we like their > network properties, like we abused <presence> in the past because it > broadcasts well. +1. >> 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. > > We lived with not knowing when the presence stream finishes, and that > was acceptable because presence is really a distributed concept so it is > impossible to know when other servers will respond. > > Rosters on the other hand are purely local to the domain concepts, so it > should be easy to say when they are over. > > On the other hand, I agree with Joe: our clients already have to deal > with roster pushes at any point in time, so I don't see the a problem here. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
