Re: [PATCH v4 02/16] Move crypto.c into libutil
[notmuch-archives.git] / ce / 56d0223041f0184ffb52f19473d6285b913f74
1 Return-Path: <sojkam1@fel.cvut.cz>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id 76F8A4196F3\r
6         for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 01:50:49 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.001\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5\r
12         tests=[BAYES_20=-0.001] autolearn=ham\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id R68tkjm7iUKA for <notmuch@notmuchmail.org>;\r
16         Wed, 14 Apr 2010 01:50:47 -0700 (PDT)\r
17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
18         by olra.theworths.org (Postfix) with ESMTP id 658C64196F2\r
19         for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 01:50:47 -0700 (PDT)\r
20 Received: from localhost (unknown [192.168.200.4])\r
21         by max.feld.cvut.cz (Postfix) with ESMTP id 9DEC919F33CF;\r
22         Wed, 14 Apr 2010 10:50:46 +0200 (CEST)\r
23 X-Virus-Scanned: IMAP AMAVIS\r
24 Received: from max.feld.cvut.cz ([192.168.200.1])\r
25         by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
26         port 10044)\r
27         with ESMTP id rA-XtrpHJjxo; Wed, 14 Apr 2010 10:50:45 +0200 (CEST)\r
28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
29         by max.feld.cvut.cz (Postfix) with ESMTP id 471A319F33D0;\r
30         Wed, 14 Apr 2010 10:50:45 +0200 (CEST)\r
31 Received: from steelpick.2x.cz (k335-30.felk.cvut.cz [147.32.86.30])\r
32         (Authenticated sender: sojkam1)\r
33         by imap.feld.cvut.cz (Postfix) with ESMTPSA id 18D80FA003;\r
34         Wed, 14 Apr 2010 10:50:44 +0200 (CEST)\r
35 Received: from wsh by steelpick.2x.cz with local (Exim 4.71)\r
36         (envelope-from <sojkam1@fel.cvut.cz>)\r
37         id 1O1yJ2-0003dr-QG; Wed, 14 Apr 2010 10:50:44 +0200\r
38 From: Michal Sojka <sojkam1@fel.cvut.cz>\r
39 To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
40 Subject: Re: [PATCH 1/4] Mailstore abstraction interface\r
41 In-Reply-To: <87aat7kznb.fsf@yoom.home.cworth.org>\r
42 References: <1270737766-29237-1-git-send-email-sojkam1@fel.cvut.cz>\r
43         <1270737766-29237-2-git-send-email-sojkam1@fel.cvut.cz>\r
44         <87aat7kznb.fsf@yoom.home.cworth.org>\r
45 Date: Wed, 14 Apr 2010 10:50:44 +0200\r
46 Message-ID: <8739yya04b.fsf@steelpick.2x.cz>\r
47 MIME-Version: 1.0\r
48 Content-Type: text/plain; charset=us-ascii\r
49 X-BeenThere: notmuch@notmuchmail.org\r
50 X-Mailman-Version: 2.1.13\r
51 Precedence: list\r
52 List-Id: "Use and development of the notmuch mail system."\r
53         <notmuch.notmuchmail.org>\r
54 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
55         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
56 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
57 List-Post: <mailto:notmuch@notmuchmail.org>\r
58 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
59 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
60         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
61 X-List-Received-Date: Wed, 14 Apr 2010 08:50:49 -0000\r
62 \r
63 On Tue, 13 Apr 2010, Carl Worth wrote:\r
64 > On Thu,  8 Apr 2010 16:42:43 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
65 > > The goal of mailstore abstraction is to allow notmuch to store tags\r
66 > > together with email messages. The abstract interface is needed because\r
67 > > people want to use different ways of storing their emails. Currently,\r
68 > > there exists implementation for two types of mailstore - plain files\r
69 > > and maildir. It is expected that additional git-based mailstore will\r
70 > > be developed later.\r
71\r
72 > I don't agree with the approach being taken here.\r
73\r
74 > I don't think that the expectation of future need is a good basis for\r
75 > adding a level of abstraction now. This gives us current costs without\r
76 > benefit.\r
77 \r
78 Thanks for the review, Carl. Since I'm interested in further development\r
79 of mailstore abstraction until it is really useful, I'd like to make the\r
80 patch series as small as possible to reduce maintenance burden. I think\r
81 I can extract some "real features" such as cat subcommand from my\r
82 patches and send them separately, perhaps in 0.3 merge window.\r
83 \r
84 > Meanwhile, the two different mail stores that you are currently support\r
85 > ("plain" and "maildir") aren't really different types. We do already\r
86 > have code within notmuch to detect whether any particular directory is a\r
87 > maildir, (with the heuristic of looking for child directories named\r
88 > "cur", "new", and "tmp"). So I think we can and should support both\r
89 > maildir and non-maildir mail storage just fine.\r
90\r
91 > The question of "once you have maildir storage, should you synchronize\r
92 > that tags" is quite separate. The answer there might be "yes", "no", or\r
93 > "let the user decide". But if it is configurable, then the configuration\r
94 > should be something like\r
95\r
96 >       [maildir]\r
97 >       synchronize_flags=yes\r
98\r
99 > rather than\r
100\r
101 >       [mailstore]\r
102 >       type=maildir\r
103 \r
104 Yes, these two mail stores share a lot of code and there is only a small\r
105 difference between them. I agree that it is cleaner for users to see\r
106 them as a single mailstore type and use configuration options to change\r
107 the behavior.\r
108 \r
109 -Michal\r