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.
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.
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.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
