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

Patch: cleanup body caching



Hi,

it rocks to see the performance on remote IMAP servers with the body caching.

However, this IMHO isn't really the way to go for several reasons.

First, mutt still has POP support and the while the code is in imap/ it's unreachable. Second: the naming conventions are totally different from the header caching, which might be confusing or is at least inconsistent.

I've started a long-term patch series which, in the end, is supposed to contain a totally refactored caching infrastructure (nice buzzword, isn't it ;-).

The first unspectacular version is at:

  <http://user.cs.tu-berlin.de/~pdmef/mutt/patches/>

as 'pdmef+patch+cache' along with a description, diff against CVS head and a dump of git logs (there it is again ;-) excluding those from CVS head (that's import since I put most of the reasoning for my local chanegs in there).

Here's what I plan to do (roughly in that order).

First, move it from imap/* out to the top level directory to make body caching available everywhere. This also needs changing the filename generation to be IMAP-independent. This is what the patch does now.

Try to port POP to it and see if POP can benefit from header caching as well. This needs to be done to see if the API makes sense.

Split up header caching into two different interfaces. There should be one for raw (but abstract) database storage. Only things like open/close, store integer, list, string, etc. should be provided. On top of that a header cache can be implemented which uses the storage backend to have clean separation of the logic.

Afterwards the body caching needs to be refactored (maybe) to see if it can benefit from the DB backend as well.

For easier maintaince and convenience, we need tools (at least built locally for developers) to work with the cache, i.e. list its contents, etc. For example, right now it's hard to tell (from user's point of view) whether a header cache file is still in use if he happens to remove a few mailboxes from the folder list.

This could be done via index files which themselves would have to be implemented using the DB storage backend. Such index files (telling what MD5-named file is what and depending on that: what's in it) could be easily extended to contain more metadata to have something like bidirectional IMAP sync, virtual folders or whatever feature requests there still are open.

Of course I'm totally open for any kind of suggestion, comments and the like. Oh, and patches. ;-)

  bye, Rocco
--
:wq!