1 Return-Path: <tomi.ollila@iki.fi>
\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 0D483431FBC
\r
6 for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 02:47:30 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\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 D7qub4AxKNYO for <notmuch@notmuchmail.org>;
\r
16 Sat, 25 Jan 2014 02:47:21 -0800 (PST)
\r
17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 8BF68431FB6
\r
19 for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 02:47:21 -0800 (PST)
\r
20 Received: from guru.guru-group.fi (localhost [IPv6:::1])
\r
21 by guru.guru-group.fi (Postfix) with ESMTP id 875031000B3;
\r
22 Sat, 25 Jan 2014 12:47:13 +0200 (EET)
\r
23 From: Tomi Ollila <tomi.ollila@iki.fi>
\r
24 To: Jani Nikula <jani@nikula.org>, Austin Clements <aclements@csail.mit.edu>,
\r
25 notmuch@notmuchmail.org
\r
26 Subject: Re: [PATCH 0/5] lib: make folder: prefix literal
\r
27 In-Reply-To: <87r47wfltb.fsf@nikula.org>
\r
28 References: <cover.1389304779.git.jani@nikula.org>
\r
29 <87y525m649.fsf@awakening.csail.mit.edu>
\r
30 <87r47wfltb.fsf@nikula.org>
\r
31 User-Agent: Notmuch/0.17+41~g8e7fabf (http://notmuchmail.org) Emacs/24.3.1
\r
32 (x86_64-unknown-linux-gnu)
\r
33 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL
\r
34 $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F
\r
35 !)g;OY^,BjTbr)Np:%c_o'jj,Z
\r
36 Date: Sat, 25 Jan 2014 12:47:13 +0200
\r
37 Message-ID: <m2zjmks5hq.fsf@guru.guru-group.fi>
\r
39 Content-Type: text/plain
\r
40 X-BeenThere: notmuch@notmuchmail.org
\r
41 X-Mailman-Version: 2.1.13
\r
43 List-Id: "Use and development of the notmuch mail system."
\r
44 <notmuch.notmuchmail.org>
\r
45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
46 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
48 List-Post: <mailto:notmuch@notmuchmail.org>
\r
49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
52 X-List-Received-Date: Sat, 25 Jan 2014 10:47:30 -0000
\r
54 On Sat, Jan 25 2014, Jani Nikula <jani@nikula.org> wrote:
\r
56 > On Fri, 24 Jan 2014, Austin Clements <aclements@csail.mit.edu> wrote:
\r
57 >> On Thu, 09 Jan 2014, Jani Nikula <jani@nikula.org> wrote:
\r
58 >>> Hi all, this series makes the folder: search prefix literal, or switches
\r
59 >>> it from a probabilistic prefix to a boolean prefix. With this, you have
\r
60 >>> to give the path from the maildir root to the folder you want in full,
\r
61 >>> including the maildir cur/new component, if any. Examples:
\r
63 >> I strongly disagree with requiring the cur/new component. The cur/new
\r
64 >> directory is an internal implementation detail of Maildir (and a rather
\r
65 >> broken one at that) and no more a part of the "folder" of a piece of
\r
66 >> mail than its final file name component. It's also the less obvious
\r
67 >> user interface; if we require the cur/new component, we *will* get
\r
68 >> people asking why their folder searches aren't working, but if we strip
\r
69 >> the cur/new component, nobody will be surprised.
\r
71 >> I think the question is not whether we should strip cur/new, but when.
\r
72 >> We've already defined a "_filename_is_in_maildir" test in
\r
73 >> lib/message.cc, which we depend on for flag sync. It's simple, but I
\r
74 >> think this would be the right thing to use for consistency.
\r
76 > I'd like to discuss some of the reasons I chose to include the cur/new
\r
77 > components. Admittedly, none of them are very strong on their own, but
\r
78 > all of them together tilted my opinion towards requiring them.
\r
80 > The way I see it, notmuch supports maildir, but does not require it. In
\r
81 > many ways the messages are just files somewhere in the directory
\r
82 > hierarchy. There are only a few cases where it matters that there are
\r
83 > cur/new/tmp directories within a directory.
\r
85 > If you strip cur and new, it becomes impossible to distinguish between
\r
86 > files in foo, foo/cur, and foo/new - and one of the reasons for changing
\r
87 > folder: in the first place is to be able to better distinguish between
\r
90 > Apparently mutt presents the difference between messages in new and cur
\r
91 > to its users (so I've been told; I've never really used mutt), and our
\r
92 > integration with mutt lacks that distinction. We could fix that by
\r
93 > requiring the cur/new components in folder: searches.
\r
95 > Speaking of consistency, compare _filename_is_in_maildir() with
\r
96 > _entries_resemble_maildir() in notmuch-new.c. What should the indexed
\r
97 > folder: prefix be if there is not all of cur, new, and tmp? We will
\r
98 > actually index files in tmp if cur or new is not present! What if the
\r
99 > missing sibling directories are added (or existing ones removed) later?
\r
100 > Where's the consistency compared to new.ignore config, which also
\r
101 > matches the cur/new components if so desired? Or consistency with
\r
102 > notmuch search --output=files?
\r
104 > My conclusion was that requiring *all* filesystem folder components
\r
105 > as-is is consistent, most versatile, agnostic to Maildir or Maildir++
\r
106 > implementation details wrt directory naming or hierarchy, without
\r
107 > difficult corner cases, simplest to implement, and unsurprising (once
\r
108 > you understand the cur/new distinction).
\r
110 > For *me* this is the more obvious user interface. And hey, I'm a user
\r
113 > Perhaps we need to have two prefixes, one of which is the literal
\r
114 > filesystem folder and another which hides the implementation details,
\r
115 > like I mentioned in my mail to Peter [1]. But consider this: my proposed
\r
116 > implementation does cover *all* use cases.
\r
118 I challenge that with my use case: my mails are arranged as follows:
\r
120 head of contents of notmuch archive prior to my involvement:
\r
122 $ find notmuch | head -5
\r
125 notmuch/6b/de820df0697ab2d235fbc8e32510d7
\r
126 notmuch/6b/917afddb116a03c45371282be58388
\r
127 notmuch/6b/10eb0bc1406f6767161f5883f328f7
\r
129 head of contents of received mail
\r
131 $ find notmuch | head -5
\r
135 received/6b/86a8937aac57721ad87f0e0e5fe6c3
\r
136 received/6b/3278d6c4c1fe7604f1404bc09acff7
\r
138 Interestingly find started with subdirectory '6b' in both cases...
\r
139 -- anyway I have 0xff + 1 subdirectories in each mail directory and
\r
140 $ md5sum received/6b/86a8937aac57721ad87f0e0e5fe6c3 outputs
\r
141 6b86a8937aac57721ad87f0e0e5fe6c3 received/6b/86a8937aac57721ad87f0e0e5fe6c3
\r
143 For me the current folder: works as I don't have collisions.
\r
145 For me a folder: search which would just work as a prefix i.e. match
\r
146 anything under given directory hierarchy would work best.
\r
148 At the end it might be that I have to hack the search for my purposes;
\r
149 more important/interesting thing is whether I need to use incompatible
\r
161 > [1] id:8761ppurfz.fsf@nikula.org
\r
projects / notmuch-archives.git / blob