Sorry for the delayed reply, I'm slowly catching up on email. Dave Cridland wrote: > On Wed Feb 27 16:06:23 2008, Peter Saint-Andre wrote: >> Fabio Forno wrote: >> > Though sending roster diffs helps. There is a new possible approach >> > I've found only after the discussion we had: use just roster push, >> > that must implemented regardlessly any optimization. The client asks >> > for the roster adding a timestamp of the last received push, and the >> > server sends changes as pushes (all timestamped) >> >> Yes, we have roster pushes so it seems like a good idea to use them (in >> general I think we should make intelligent use of everything we've >> already defined, such as presence and rosters and roster pushes and so >> on -- other real-time communication technologies don't have these >> features at the base level, so it's to our advantage to use them). I >> think that something like what you suggest might work well. >> >> Also, before the devcon Dave Cridland mentioned that he didn't like the >> XEP-0150 approach but at the devcon we somehow didn't hear from him on >> this topic, so perhaps he could weigh in with his ideas here. > > At the devcon, the more interesting discussion was concerning quiescing > the stream, etc. We decided that, as I recall, we'd not bother > discussing startup optimizations, mainly because we basically knew the > score there, and with our unnamed external expert talking about other > stuff, we concentrated on that.
Yes, I'm working to add the "session hush" and "session pause" features to XEP-0198. They are harder to define, so I'm punting in part by defining the startup optimization stuff first. :) > So... There's three options in the roster push optimization space. All > involve the client and server maintaining a "timestamp" for the roster > as a whole, and/or each individual item within it. The timestamp might > be opaque (like ETags), a strictly increasing sequence number, or a > modified, strictly increasing, timestamp. It actually doesn't matter, > but the latter two allow for interesting things. > > Whichever, the server MUST include the timestamp-like thing in each > roster push. > > 1) Client says "I got the roster at this point in time". Server says > either "Then you have it." or "Then I'll send you the new roster." > > This is basically the ETags method. I don't like this, because I add > people to my Roster, and reorganize those that are there, relatively > often, and this would incur a full dowload each time. > > 2) Client says "I have the roster as of this point in time". Server says > "Here's all the changes since then.". > > This is obviously the best option in terms of efficiency, but it, too, > has problems. The key issue is that roster entries won't die - instead, > they'll be maintained along with a timestamp when deleted, in order that > the server can tell a client it's gone. > > 3) Client says "I have the roster as of this point in time". Server > either says "Here's the changes" or "Here's the whole roster", depending > on whether it can find all deletions. > > This is basically addressing the shortfall of the above, and allows for > a single RTT self-correcting error case. I like this one best, and it's > pretty easy to implement. Yes I think we've done that in the emerging roster-versioning spec. > I also have a fondness for modified strictly increasing timestamps, but > implementors need to appreciate that computer clocks go backwards, so > they need to remember to handle odd cases like that by "letting time > catch up" - just using a few ms later than the last timestamp until the > real time is greater than the last timestamp. > > This would allow clients to show the "last changed" date/time of the > roster entry in a mostly realistic manner. Personally I have a fondness for start-at-zero and increment-by-one, as you can see in the roster-versioning spec. We're not exactly trying to synchronize, since we trust the server to be in charge of the roster version. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
