Re: [Evolution-hackers] compression for folders?

[Craig Ringer <craig postnewspapers com au>]

On Wed, 2004-05-12 at 05:13, Jeffrey Stedfast wrote:

> but it's slower than if hi, ho, and fun were all gzipped in one stream.
> to find the end of the gzipped 'hi' stream, you have to continually test
> of EOS by comparing 8 bytes (crc32 and isize). If they match, then
> you've found the end of the gzip stream, else continue.

I've been watching this discussion, and though I'm not interested in
client-side mail archival myself, I have a suggestion about how it might
be accomplished vaguely efficiently, though at the cost of some
complexity.

Perhaps it might be reasonable to compress archived folders into (say)
~100kb chunks, and maintain header indexes of each chunk? That way,
displaying headers doesn't involve accessing the mailboxes at all, and
when the user tries to access a message you only need to seek over a
small compressed file to get the message. The folder would be add-only,
and a new compressed file would be created whenever the size of
uncompressed messages in the folder reached a certain size threshold.

Downside: quite a bit of work to write and somewhat complex.
Upside: if I'm thinking straight, should be reasonably efficient.

Personally, I'm all for "just leave it on the IMAP server, dammit" but
that won't work for most users.

Craig Ringer