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
afterward.
You don't need to read them, just say "Ah, yes, QTLS, hmmm", then nod
sagely.
Or you could look at:
QTLS/QUICKSTART:
Two flavours; simple and full:
http://tools.ietf.org/html/draft-fanf-smtp-quickstart-a-00
http://tools.ietf.org/html/draft-fanf-smtp-quickstart-b-00
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.
Then there's this evil trick of mine, which you can use in concert
with Tony's insane hackery:
http://tools.ietf.org/html/draft-cridland-sasl-tls-sessions-00
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.
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. 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.
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.
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
