[RFC PATCH 00/13] Modular message store code
Ethan Glasser-Camp
glasse at cs.rpi.edu
Thu Mar 1 05:51:06 PST 2012
On 02/15/2012 07:56 PM, Mark Walters wrote:
> Obviously I have not looked at the patch set in detail yet but I have a
> quick question. Since you are allowing more general filenames anyway
> couldn't you encode mailstore in filename? Eg
> mbox://some-path[:byte-postion], or "imap://server..."
>
> This would allow lots of different types of mailstore to be used
> concurrently, and would push all the mailstore knowledge down into the
> file handling functions and away from the callers of file handling
> functions.
>
> Of course there may be lots of good reasons why this doesn't work.
>
Hi, sorry for the delay.
As far as I can tell, currently notmuch stores message filenames in
Xapian as paths relative to the top-level maildir. I think this is done
so that the maildir can be moved and, if the .notmuch-config is updated,
mails are correctly detected and not duplicated. This would be
especially important when you're talking about changing IMAP servers or
CouchDB instances.
If I wanted to preserve this feature, the URIs stored as filenames would
have to be relative to a given mailstore. For example,
maildir://maildir-1/INBOX/some-filename could mean the file
INBOX/some-filename in a maildir at /home/user/some-maildir. But then
this raises the two following issues:
- How does information about mailstores -- for example, that maildir-1
=> /home/user/some-maildir -- enter the library? Do we stick all of that
information in notmuch_database_t, and then pass a reference to it in
notmuch_message_file_open? Perhaps a global
notmuch_mailstore_register(name, parameters..) registry? Or maybe a
notmuch_mailstore_info type that gets passed around similarly to the
mailstore type in this patch set?
- Do we mandate that all the filenames in the database be updated or do
we just assume non-URI-style filenames are relative to some "default"
mailstore?
All of which is a fancy way of saying I haven't had the time to write
the code necessary to explore this idea but think something like it will
be necessary to support the obviously-valuable feature of multiple
mailstores. Depending on your answer to the first question, I guess the
patch series might or might not be a useful starting point.
Thanks for your feedback,
Ethan
More information about the notmuch
mailing list