--- /dev/null
+Return-Path: <glasse@cs.rpi.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 7929E431E82\r
+ for <notmuch@notmuchmail.org>; Thu, 1 Mar 2012 05:51:29 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.786\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.614] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id GxJNqsU10Z3d for <notmuch@notmuchmail.org>;\r
+ Thu, 1 Mar 2012 05:51:29 -0800 (PST)\r
+Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu\r
+ [128.113.126.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS\r
+ id E24D3431FAE for <notmuch@notmuchmail.org>; Thu, 1 Mar 2012 05:51:28 -0800\r
+ (PST)\r
+X-Hash: SCtCte|8a33544e880fe0f58d8d926176accedc9741b698|60d234bb52c76d228045603c2935f730\r
+X-Countries: Cameroon, United States\r
+X-SMTP-From: accepted <glasse@cs.rpi.edu> [41.202.193.168] [41.202.193.168]\r
+ ([192.168.1.16]) {Cameroon}\r
+DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cs.rpi.edu; h=\r
+ message-id:date:from:mime-version:to:cc:subject:references\r
+ :in-reply-to:content-type:content-transfer-encoding; s=default;\r
+ i=glasse@cs.rpi.edu; t=1330609887; x=1331214687; l=2291; bh=23J\r
+ Sr8hXDLxZ99JtyVXFCUrzqbE=; b=NkDOKVyXmvs6/HkMHX3N6t/Eut5gdMeG41A\r
+ 8LGP6CBZAp71iv5WKEi6uVJjnT4AZKDH2o2W/hP0QmKvh1+kIlWxazJiD/9Z/xDz\r
+ RxIF0yStvOUSqxdavOpX6Fv9mHn9sRQXVwojiDOsp8LwKMt42cn0CzKVJnHTjV3N\r
+ yHeQhcCg=\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=cs.rpi.edu; h=message-id\r
+ :date:from:mime-version:to:cc:subject:references:in-reply-to\r
+ :content-type:content-transfer-encoding; q=dns; s=default; b=amj\r
+ mW9Cj+/qRUqi1aExMWH9ATqLZtglLeNjfsJSPGq1YzPDCeAuGHGSu8lCryL0bKfL\r
+ aMJpFkVTJyGEaprx93RHLAb51JjzcHDPc4Ns6hNBWdMGMuT883Bbl7XApwbR+LFG\r
+ wzL1s2RNwTKWfx7C/tKqo9XV02t3DD11JAwKGv4I=\r
+X-Spam-Info: -2.7; ALL_TRUSTED,BAYES_00\r
+X-Spam-Scanned-By: cliffclavin.cs.rpi.edu using SpamAssassin 3.2.5 (hard limit\r
+ 15)\r
+Authentication-Results: cliffclavin.cs.rpi.edu;\r
+ DKIM=neutral (none) header.from=glasse@cs.rpi.edu;\r
+ SPF=neutral (mfrom;\r
+ Mechanism '?all' matched) smtp.mail=glasse@cs.rpi.edu\r
+X-Auth-Passed: cliffclavin.cs.rpi.edu:q21DpElp089935 Auth:glasse\r
+X-Virus-Scanned-By: cliffclavin.cs.rpi.edu\r
+Received: from [192.168.1.16] ([41.202.193.168]) (authenticated bits=0)\r
+ by cliffclavin.cs.rpi.edu (8.14.3/8.14.3) with ESMTP id q21DpElp089935\r
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);\r
+ Thu, 1 Mar 2012 08:51:19 -0500 (EST)\r
+ (envelope-from glasse@cs.rpi.edu)\r
+Message-ID: <4F4F7ECA.5010206@cs.rpi.edu>\r
+Date: Thu, 01 Mar 2012 08:51:06 -0500\r
+From: Ethan Glasser-Camp <glasse@cs.rpi.edu>\r
+User-Agent: Mozilla/5.0 (X11; Linux i686;\r
+ rv:8.0) Gecko/20111124 Thunderbird/8.0\r
+MIME-Version: 1.0\r
+To: Mark Walters <markwalters1009@gmail.com>\r
+Subject: Re: [RFC PATCH 00/13] Modular message store code\r
+References: <1329343326-16410-1-git-send-email-glasse@cs.rpi.edu>\r
+ <87y5s3k344.fsf@qmul.ac.uk>\r
+In-Reply-To: <87y5s3k344.fsf@qmul.ac.uk>\r
+Content-Type: text/plain; charset=ISO-8859-1; format=flowed\r
+Content-Transfer-Encoding: 7bit\r
+X-Scanned-By: MIMEDefang 2.67 on 128.113.126.25\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 01 Mar 2012 13:51:29 -0000\r
+\r
+On 02/15/2012 07:56 PM, Mark Walters wrote:\r
+> Obviously I have not looked at the patch set in detail yet but I have a\r
+> quick question. Since you are allowing more general filenames anyway\r
+> couldn't you encode mailstore in filename? Eg\r
+> mbox://some-path[:byte-postion], or "imap://server..."\r
+>\r
+> This would allow lots of different types of mailstore to be used\r
+> concurrently, and would push all the mailstore knowledge down into the\r
+> file handling functions and away from the callers of file handling\r
+> functions.\r
+>\r
+> Of course there may be lots of good reasons why this doesn't work.\r
+>\r
+Hi, sorry for the delay.\r
+\r
+As far as I can tell, currently notmuch stores message filenames in \r
+Xapian as paths relative to the top-level maildir. I think this is done \r
+so that the maildir can be moved and, if the .notmuch-config is updated, \r
+mails are correctly detected and not duplicated. This would be \r
+especially important when you're talking about changing IMAP servers or \r
+CouchDB instances.\r
+\r
+If I wanted to preserve this feature, the URIs stored as filenames would \r
+have to be relative to a given mailstore. For example, \r
+maildir://maildir-1/INBOX/some-filename could mean the file \r
+INBOX/some-filename in a maildir at /home/user/some-maildir. But then \r
+this raises the two following issues:\r
+\r
+- How does information about mailstores -- for example, that maildir-1 \r
+=> /home/user/some-maildir -- enter the library? Do we stick all of that \r
+information in notmuch_database_t, and then pass a reference to it in \r
+notmuch_message_file_open? Perhaps a global \r
+notmuch_mailstore_register(name, parameters..) registry? Or maybe a \r
+notmuch_mailstore_info type that gets passed around similarly to the \r
+mailstore type in this patch set?\r
+\r
+- Do we mandate that all the filenames in the database be updated or do \r
+we just assume non-URI-style filenames are relative to some "default" \r
+mailstore?\r
+\r
+All of which is a fancy way of saying I haven't had the time to write \r
+the code necessary to explore this idea but think something like it will \r
+be necessary to support the obviously-valuable feature of multiple \r
+mailstores. Depending on your answer to the first question, I guess the \r
+patch series might or might not be a useful starting point.\r
+\r
+Thanks for your feedback,\r
+\r
+Ethan\r
+\r
projects / notmuch-archives.git / commitdiff