[Dovecot] Capability COMPRESS implemented?

Ed W lists at wildgooses.com
Fri Jun 26 01:21:17 EEST 2009


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


More information about the dovecot mailing list