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