[Standards] mobile optimizations
stpeter at stpeter.im
Wed Mar 5 02:17:53 UTC 2008
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards