Timo Sirainen wrote:
On Thu, 2009-06-25 at 21:49 +0100, Ed W wrote:
Timo normally chimes in pretty fast on these types of questions - Any
chance of a yay/nay on the COMPRESS option Timo?
Maybe. I'm kind of busy with other stuff though..
Understood
Please take it as a +1 interested here. I guess you don't take external
paid work now...
Yeah, not for next half a year at least. Anyway, it would basically need
istream and ostream implementations for zlib. istream implementation
kind of already exists in zlib plugin, except it's using gz*() functions
instead of doing everything in memory. So:
I might have missed the subtleties since it's a while since I wrote
anything against the gz interface, but there shouldn't be much
difference between interfaces I think?
The only difference is where the buffering is going surely?
The naive implementation would flush whenever you would normally flush
the net buffers, but the notes in the RFC point out that you can in fact
shoot for some clever stuff and vary your compression params according
to the type of data. Having tried all this stuff a bunch I can say that
it's a good thought, but unless you are hyper bandwidth constrained then
zlib uses such small buffers that it's really not likely to make more
than a tiny difference... (and if you are mega bandwidth constrained
then don't use IMAP at all...)
Hope you will put it on your TODO anyway... (pretty please...)
FWIW I notice a significant speedup using our compressing proxy over
even a 10mbit connection, so I am pretty sure this will lead to a
significant improvement in response speeds for a lot of folks
Ed W
