I tried this a couple of years ago, and the result was that the files
were *much* smaller but reading/saving the header files was an order
of magnitude slower.  Maybe things have improved since then -- if
someone wants to benchmark times to save a big newsgroup with &
without compression I'd love to see the results.

I think the best way to compress the cache for smaller disk usage and faster
startup would be to rewrite the cache to use something like gdbm. This would
reduce internal fragmentation.

For example :

message/cache contains 3057 files
du -hs message/cache -> 14MB
data size -> 8MB

Everytime i start pan, it's a pain to hear my disk ... This is a real issue ...

I tried this out again somewhere around 0.95.  The space
savings were very good (though less than before, since the
new data files are better organized), but reading was
5x slower and saving was more than 10x slower than
without compression.

i guess that every layout but one file per message would improve performance.

the next version will employ a db backend if i'm concerned, so wontfix.