[Standards] mobile optimizations
stpeter at stpeter.im
Fri Feb 15 16:06:33 UTC 2008
Dave Cridland wrote:
> On Thu Feb 14 22:49:20 2008, Peter Saint-Andre wrote:
>> On Thu, Feb 14, 2008 at 08:39:29PM +0000, Dave Cridland wrote:
>> > Lots of work from mobile email (ie, Lemonade) is transferrable
>> here. > It'd be really nice if Tony Finch was coming, since he could
>> talk us > through QTLS and QUICKSTART - they're SMTP fast startup
>> work he did a > while back. Very interesting, but didn't make it into
>> the Lemonade > Profile itself.
>> Do you have references? At least we could read up on it so we can
>> discuss it intelligently at the devcon, then pester Tony with questions
> You don't need to read them, just say "Ah, yes, QTLS, hmmm", then nod
> Or you could look at:
> Two flavours; simple and full:
> Both are really scary. I've always been a big fan of the detailed
> round-trip analysis at the end. I'm hoping Tony will notice this thread
> and do something similar for XMPP.
I haven't read those yet, because you scared me off. :P
> Then there's this evil trick of mine, which you can use in concert with
> Tony's insane hackery:
That's interesting. The reuse (overloading?) of SASL EXTERNAL is
creative. :) I tend to agree with your speculation that we might want to
define a family of EXTERNAL-like mechanisms, rather than forcing a wide
variety of credential types (X.509 certs, IPSec, reauth) into the one
> Otherwise, the remaining tricks we can use are fast resynchronization
> from a known state point, and fast reconnection.
> Fast reconnection is essentially the case where there is a short time
> period between the end of the last connection and the beginning of the
> next, such that both ends can maintain full state. XEP-0198 is basically
> fully addressing this - it allows for the somewhat curious case of a
> client noticing it's offline and reconnecting before the server has a
> chance to notice what's happening.
Yes, I need to update that spec real soon now (to incorporate some
feedback that Justin hasn't had time to work in).
> Fast resynchronization is somewhat more complex - roster optimizations
> is one area we need, and I think I see a clear way of doing this.
> Whether it's implementable by everyone I don't know. Essentially, it
> would be a monotonically increasing modification sequence on the roster,
> and whenever a roster entry is changed, increasing the sequence and
> stamping the roster entry with the current value.
Rosters are so core to how both clients and servers work that I somewhat
doubt if changes thereto will see wide implementation or deployment
> It's more efficient
> than ETags on the entire roster, and would then give clients a simple
> "tell me stuff that's changed" operation. Roster removals would still be
> painful, but those are rather rarer than changes and additions, I think.
> This is basically lifting RFC 4551's conditional fetch and reapplying it
> to rosters.
Yay, another RFC to read. :)
> Presence and PubSub resynchronization I think would need addressing for
> this, too, but I don't have a clear idea of what can be done there.
> One thing we can do is buffer... If you can get all the initial presence
> splurge into a single buffer before you compress/encrypt/send, you'll
> get much better compression.
>> >> 5. Advisability of presence-only connections (no roster-get, just send
>> >> presence and whatever you receive is nice).
>> > If you can optimize the roster fetch sufficiently, this really
>> isn't > required.
>> Probably not.
> Oh, definitely not - the only excess would be the first roster fetch -
> subsequent ones will yield no data in normal cases. Obviously we still
> need to discuss not fetching the roster carefully, since it'll be a
> useful tactic until we get an optimized roster thing widely deployed.
More to talk about at the devcon...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards