From ae6a233ea1bf89af1b1383ec6b06a40e8343894c Mon Sep 17 00:00:00 2001 From: Ethan Glasser-Camp Date: Fri, 2 Mar 2012 08:51:06 +1900 Subject: [PATCH] Re: [RFC PATCH 00/13] Modular message store code --- 65/63a6eb30be1b568a14f2f31bc79ed8e4fb90fe | 133 ++++++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 65/63a6eb30be1b568a14f2f31bc79ed8e4fb90fe diff --git a/65/63a6eb30be1b568a14f2f31bc79ed8e4fb90fe b/65/63a6eb30be1b568a14f2f31bc79ed8e4fb90fe new file mode 100644 index 000000000..4d77e7fbe --- /dev/null +++ b/65/63a6eb30be1b568a14f2f31bc79ed8e4fb90fe @@ -0,0 +1,133 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 7929E431E82 + for ; Thu, 1 Mar 2012 05:51:29 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -1.786 +X-Spam-Level: +X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 + tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, + RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.614] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id GxJNqsU10Z3d for ; + Thu, 1 Mar 2012 05:51:29 -0800 (PST) +Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu + [128.113.126.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS + id E24D3431FAE for ; Thu, 1 Mar 2012 05:51:28 -0800 + (PST) +X-Hash: SCtCte|8a33544e880fe0f58d8d926176accedc9741b698|60d234bb52c76d228045603c2935f730 +X-Countries: Cameroon, United States +X-SMTP-From: accepted [41.202.193.168] [41.202.193.168] + ([192.168.1.16]) {Cameroon} +DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cs.rpi.edu; h= + message-id:date:from:mime-version:to:cc:subject:references + :in-reply-to:content-type:content-transfer-encoding; s=default; + i=glasse@cs.rpi.edu; t=1330609887; x=1331214687; l=2291; bh=23J + Sr8hXDLxZ99JtyVXFCUrzqbE=; b=NkDOKVyXmvs6/HkMHX3N6t/Eut5gdMeG41A + 8LGP6CBZAp71iv5WKEi6uVJjnT4AZKDH2o2W/hP0QmKvh1+kIlWxazJiD/9Z/xDz + RxIF0yStvOUSqxdavOpX6Fv9mHn9sRQXVwojiDOsp8LwKMt42cn0CzKVJnHTjV3N + yHeQhcCg= +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= +X-Spam-Info: -2.7; ALL_TRUSTED,BAYES_00 +X-Spam-Scanned-By: cliffclavin.cs.rpi.edu using SpamAssassin 3.2.5 (hard limit + 15) +Authentication-Results: cliffclavin.cs.rpi.edu; + DKIM=neutral (none) header.from=glasse@cs.rpi.edu; + SPF=neutral (mfrom; + Mechanism '?all' matched) smtp.mail=glasse@cs.rpi.edu +X-Auth-Passed: cliffclavin.cs.rpi.edu:q21DpElp089935 Auth:glasse +X-Virus-Scanned-By: cliffclavin.cs.rpi.edu +Received: from [192.168.1.16] ([41.202.193.168]) (authenticated bits=0) + by cliffclavin.cs.rpi.edu (8.14.3/8.14.3) with ESMTP id q21DpElp089935 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); + Thu, 1 Mar 2012 08:51:19 -0500 (EST) + (envelope-from glasse@cs.rpi.edu) +Message-ID: <4F4F7ECA.5010206@cs.rpi.edu> +Date: Thu, 01 Mar 2012 08:51:06 -0500 +From: Ethan Glasser-Camp +User-Agent: Mozilla/5.0 (X11; Linux i686; + rv:8.0) Gecko/20111124 Thunderbird/8.0 +MIME-Version: 1.0 +To: Mark Walters +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 +X-Scanned-By: MIMEDefang 2.67 on 128.113.126.25 +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 01 Mar 2012 13:51:29 -0000 + +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 + -- 2.26.2