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!