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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
