On Fri Jun 5 23:57:06 2009, Peter Saint-Andre wrote:
Fabio Forno has found some good results with SIFT on a mobile phone:
http://blog.bluendo.com/ff/xmpp-and-compression-a-little-experiment
Hmmm - I had a long chat with Forno the other evening, and I've been
meaning to write it up in a more formal way for us all to share...
The general idea is that instead of SIFT at all, we have a single
command which simply says "Don't send my presence *until* you've
something else to send me." - or turns off that state. Nothing gets
dropped, just delayed, maybe by a maximum time.
So <presence/> gets buffered until either a <message/>, or an <iq/>,
needs sending. The client can flush the pending presence in a number
of ways, the most obvious one being simple using a XEP-0199 ping -
the response being quite sufficient to flush the presence down.
The user experience looks roughly as if presence is sometimes out of
date for a short while, but if a message arrives, it would "push
down" any delayed presence updates, so it wouldn't be often.
This is, I'd note, a pretty simple protocol to implement, and the
interesting thing about Fabio's experiment is that it shows it'd give
benefits.
If we want to get complicated, we can point out that if we're
buffering presence anyway, we might collapse presence stanzas that
are overtaken by events - so if you go away, then xa, then offline,
the server *might* drop the away/xa changes, and just give the phone
a single offline.
Now, the reason I don't think the rest of SIFT helps is that I'm not
convinced that much "unsolicited" <iq/> traffic actually happens,
because well-behaved actors, at least, will check the disco#info and
only send <iq/> stanzas supported by the remote end. There are
exceptions, such as version queries, vcards from MUC (please, folks,
fix those), and pings - the latter, of course, rather relies on
getting through.
Actually *dropping* data just strikes me as poor - I think we can do
much better than that.
FWIW, I *do* think that people want to have the concept of a "session
roster" vs "full roster", but I think that's a different problem to
solve. (And one that's quite easy, too, but harder to implement).
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
