Re: [RFC PATCH 00/13] Modular message store code

[Ethan Glasser-Camp <glasse@cs.rpi.edu>]

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