On Tue, Jan 13, 2009 at 6:22 PM, Jehan <[email protected]>wrote:
> > Hi, > > Peter Saint-Andre;6012 Wrote: > > > > I think there may already be a bug report filed about this. I know we > > discovered some strange ejabberd behavior related to compression and > > TLS > > at jabber.org when we required the use of TLS back in October (you > > could > > get around the TLS requirement if you negotiated compression first, or > > something like that). > > > > Ok I found it: > https://support.process-one.net/browse/EJAB-499 > > 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. > > 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... > Regards, > > Jehan > > > -- > Jehan > ------------------------------------------------------------------------ > Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 > View this thread: http://www.jabberforum.org/showthread.php?t=1308 > > Hi, I'd say a lot people, including myself, see compression more as an optional feature of a protocol. It's nice to have, so you can adjust traffic characteristics to your current environment, like trading computation power to bandwidth and latency. However, encryption is a MUST have for most of us on the list. In Psi for instance you can chose whether to compress or not. I for one am fine with trading my and the server's computation power in less traffic. Cheers, Tobias
