Hi, * Brendan Cully [06-04-28 15:18:57 -0700] wrote:
On Friday, 28 April 2006 at 21:22, Rocco Rutte wrote:
I'm not sure your four-level cache isn't overkill, and I doubt message 'packs' will be a win. Unlike your typical git directory, the body cache isn't append-only. Remember, the headers are already cached in a single file, so body opens are actually much nicer when they're already in their own files.
I know. I sometimes tend to go with overly complicated solutions first before finding simpler ones.
On the other hand, if one really wants to start implementing something like syncing local and IMAP folders or virtual folders for easier cross-mailbox search, it could help if there was something like an abstract interface to information. Without it, these mechanisms would have to be implemented fully on their own. (What I mean is that with a well design abstract interface, such things just need to extract the right information and put it together instead of implementing all parts of it again)
Of course, _if_ one really wants to implement it. There're feature requests open for such things (but that just means that there are feature requests open and not that it really has to be done.)
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.
ok, I guess.
That's what I did so far. Version 5 of the patch moves your code from imap/message.c to bcache.[ch] and adds the protocol to the path (i.e. 'imap:user@host' instead of just 'user@host') plus $message_cachedir.
For POP, now message file names are just the POP server's UIDL but the rest is quite the same.
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.
IMHO that's because the current naming scheme is silly. If the names reflected the value of $folder directly we wouldn't need tools.
I don't in general want to use MD5 names in all places. I can well live with other names (derived from $folder and path). But I think the body cache should look quite similar to the header cache for consistency.
That's also what I meant with "melting" both mechanisms. For example, we could simply store a folder's header cache as file 'header.db' in the same directory where the messages are stored now so that one could move the cache from one machine to another.
bye, Rocco -- :wq!