On Tue Jan 13 17:22:42 2009, Jehan wrote:
As people said on this thread, we can see that the implementation
used
by ejabberd does not include TLS compression, but apparently it is
complicated because the TLS RFC is not accurate enough about
compression
methods.
Given that one of the authors of that RFC reads this list, I'd take
cover right about now.
Incidentally, I can get TLS compression to jabber.org, but not from,
so I suspect they're confused by the utterly useless OpenSSL
documentation.
They also note an interesting information from a Google developper
stating that compression increases significantly computation power,
hence battery life decreases (annoying especially for instance for
laptops I guess). But also will we really gain from the compressed
data
then (time, power, resource use, or even environmental
consideration if
you want!)? Maybe compressing streams is just a "false good" idea...
In general, encryption is a lot more expensive than
encryption+compression, because encryption per-octet is a lot more
expensive than compression, per-octet.
On top of that, transmission power costs are very high on mobile
handsets, and I'm told by people who've been in the mobile business a
lot longer than Google that you'd have to really go some to have a
compression algorithm so expensive in computation power that it
outweighed the transmission power saving.
Google's discussion is about replacing compression of XML with a
compact representation of data vaguely similar to XMPP, and has very
little to do with this discussion.
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
