DomainKey-Signature: a=rsa-sha1; c=nofws; d=cs.rpi.edu; h=message-id
	:date:from:mime-version:to:cc:subject:references:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=default; b=amj
	mW9Cj+/qRUqi1aExMWH9ATqLZtglLeNjfsJSPGq1YzPDCeAuGHGSu8lCryL0bKfL
	aMJpFkVTJyGEaprx93RHLAb51JjzcHDPc4Ns6hNBWdMGMuT883Bbl7XApwbR+LFG
	wzL1s2RNwTKWfx7C/tKqo9XV02t3DD11JAwKGv4I=
Message-ID: <4F4F7ECA.5010206@cs.rpi.edu>
Date: Thu, 01 Mar 2012 08:51:06 -0500
From: Ethan Glasser-Camp <glasse@cs.rpi.edu>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Walters <markwalters1009@gmail.com>
Subject: Re: [RFC PATCH 00/13] Modular message store code
References: <1329343326-16410-1-git-send-email-glasse@cs.rpi.edu>
	<87y5s3k344.fsf@qmul.ac.uk>
In-Reply-To: <87y5s3k344.fsf@qmul.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: notmuch@notmuchmail.org
Precedence: list

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