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
