<<< Date Index >>>     <<< Thread Index >>>

Re: mutt cache sensitivity



Hi,

* Paul Walker [07-03-29 14:30:48 +0100] wrote:

Once we find a solution for aborted writes, I think the user is
responsible for maintaince of the cache as he's it now for header cache
too.

And this is one of the reasons I don't like the header cache much. It makes
things faster, but I'm kind of uncomfortable with the number of people
coming up in the last X months with reports of segfaults who've been told to
delete their cache and restart. It makes mutt significantly more fragile.

First, it's still a developer version. :)

Second, these problems are more or less solved. The header cache does checksum validation on its own, so we only need to bump an internal id field upon each incompatible layout change. Mutt then silently does the right thing. The crashes are mostly gone, the only symptom should be that mutt exits with "out of memory" (which is horrible, but better than crashing).

I also personally believe that if a program is going to have a cache, it
should maintain it, not the user. Firefox, IE, Opera, Outlook, Pegasus etc.
don't just grow caches without bound.

That's likely because of the architecture of the header cache. I think most of these tools roll their own caching while mutt uses database managers. I'm not familiar enough with these to tell if there's a method to get all current keys, but if: that should be used upon mailbox opening to see what mails we have, what the cache has an remove obsolete ones (the same counts for message caching, the POP part already does it).

In case of incompatible changes, I think mutt should silently delete the old file and build a new cache file. But IIRC the checksum isn't per database but per message, and I didn't check what mutt does in checksum mismatch cases, but it should delete the old entry. I think the point behind this architecture is that it should be possible to run mutt with different hcache layouts on the same cache (but I'm not sure).

Btw, the header cache IMHO is something that needs to refactored quite a lot before 1.6 so that hopefully prior to .16 someone will do it so that .16 can be used for heavy testing.

  bye, Rocco
--
:wq!