1 Return-Path: <m.walters@qmul.ac.uk>
\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 9B667431FD4
\r
6 for <notmuch@notmuchmail.org>; Sun, 1 Jul 2012 09:48:53 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5
\r
12 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,
\r
13 NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id l0mhZzKend9t for <notmuch@notmuchmail.org>;
\r
17 Sun, 1 Jul 2012 09:48:51 -0700 (PDT)
\r
18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])
\r
19 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 1713D431FAF
\r
22 for <notmuch@notmuchmail.org>; Sun, 1 Jul 2012 09:48:51 -0700 (PDT)
\r
23 Received: from smtp.qmul.ac.uk ([138.37.6.40])
\r
24 by mail2.qmul.ac.uk with esmtp (Exim 4.71)
\r
25 (envelope-from <m.walters@qmul.ac.uk>)
\r
26 id 1SlNKC-0006Y7-NZ; Sun, 01 Jul 2012 17:48:46 +0100
\r
27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]
\r
29 by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)
\r
30 (envelope-from <m.walters@qmul.ac.uk>)
\r
31 id 1SlNKC-0002Tw-DJ; Sun, 01 Jul 2012 17:48:40 +0100
\r
32 From: Mark Walters <markwalters1009@gmail.com>
\r
33 To: Ethan <ethan.glasser.camp@gmail.com>
\r
34 Subject: Re: [RFC PATCH 00/14] modular mail stores based on URIs
\r
36 <CAOJ+Ob0MSOez2MvD2fCgF7t32kFPk4g2+xCud88QmBLt_b5pOA@mail.gmail.com>
\r
37 References: <1340656899-5644-1-git-send-email-ethan@betacantrips.com>
\r
38 <877gutnmf1.fsf@qmul.ac.uk>
\r
39 <CAOJ+Ob0Kw0Kkhh9C27Xv9gvqtNowzQiNqrLAtvti7fL8NND2+w@mail.gmail.com>
\r
40 <87k3yrmahu.fsf@qmul.ac.uk>
\r
41 <CAOJ+Ob0MSOez2MvD2fCgF7t32kFPk4g2+xCud88QmBLt_b5pOA@mail.gmail.com>
\r
42 User-Agent: Notmuch/0.13.2+70~gb6a56e7 (http://notmuchmail.org) Emacs/23.4.1
\r
43 (x86_64-pc-linux-gnu)
\r
44 Date: Sun, 01 Jul 2012 17:48:36 +0100
\r
45 Message-ID: <87lij32zrv.fsf@qmul.ac.uk>
\r
47 Content-Type: text/plain; charset=us-ascii
\r
48 X-Sender-Host-Address: 94.192.233.223
\r
49 X-QM-SPAM-Info: Sender has good ham record. :)
\r
50 X-QM-Body-MD5: aca816c7db7a5308d47f64aa70561ee3 (of first 20000 bytes)
\r
51 X-SpamAssassin-Score: -1.8
\r
52 X-SpamAssassin-SpamBar: -
\r
53 X-SpamAssassin-Report: The QM spam filters have analysed this message to
\r
55 spam. We require at least 5.0 points to mark a message as spam.
\r
56 This message scored -1.8 points.
\r
57 Summary of the scoring:
\r
58 * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,
\r
60 * [138.37.6.40 listed in list.dnswl.org]
\r
61 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
\r
62 provider * (markwalters1009[at]gmail.com)
\r
63 * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
\r
65 * 0.5 AWL AWL: From: address is in the auto white-list
\r
66 X-QM-Scan-Virus: ClamAV says the message is clean
\r
67 Cc: notmuch@notmuchmail.org
\r
68 X-BeenThere: notmuch@notmuchmail.org
\r
69 X-Mailman-Version: 2.1.13
\r
71 List-Id: "Use and development of the notmuch mail system."
\r
72 <notmuch.notmuchmail.org>
\r
73 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
74 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
75 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
76 List-Post: <mailto:notmuch@notmuchmail.org>
\r
77 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
78 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
79 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
80 X-List-Received-Date: Sun, 01 Jul 2012 16:48:53 -0000
\r
82 On Sun, 01 Jul 2012, Ethan <ethan.glasser.camp@gmail.com> wrote:
\r
83 > Thanks for going through it, I know there's a lot to go through..
\r
85 > On Thu, Jun 28, 2012 at 4:45 PM, Mark Walters <markwalters1009@gmail.com>wrote:
\r
87 >> I was thinking of just having one mail root and inside that there could
\r
88 >> be maildirs and mboxes. Everything would still be relative to the root.
\r
91 > I'm hesitant to have directories that contain maildirs and mboxes. It
\r
92 > should be possible to unambiguously distinguish between a maildir file and
\r
93 > an mbox file (mboxes always start with "From ", no colon) but it sounds
\r
96 Well I was thinking you would still need to add specific sub-directories
\r
97 of db_path that might contain mboxes.
\r
99 >> 1. Are URIs the way to specify individual messages, despite bremner's
\r
100 >> > concerns about too much of the API being strings? Is adding another
\r
102 >> > is the easiest way to parse URIs?
\r
104 >> In my opinion the nice thing about using strings is that it does not
\r
106 >> any changes to the Xapian database to store them. I think using URIs may
\r
107 >> not be best though as they seem to be annoying to parse (as filenames
\r
108 >> can contain the same characters) and you seem to need to work around the
\r
109 >> parser in some cases.
\r
112 > I think that's more the fault of the parser than of the URIs. If glib came
\r
113 > with a parser, that would be great. There aren't a lot of options for
\r
114 > pure-C URI parsing. Besides uriparser, there's also some code in the W3C
\r
115 > sample code library, but it looked like integrating it would be a pain so I
\r
118 > I wonder if the following would be practical: use // as the field
\r
121 >> e.g. mbox://filename//start_of_message+length
\r
123 >> I think 2 consecutive slashes // is about the only thing we can assume
\r
124 >> is not in the path or filename. Since it is not in the filename I think
\r
125 >> parsing should be trivial (thus avoiding the extra library).
\r
128 > Can you explain what you mean when you say that two consecutive slashes
\r
129 > can't appear in a URL? Ordinary filesystem paths can contain them, and so
\r
130 > can file: URLs. (I just looked up file:///home/ethan///////tmp and Firefox
\r
131 > handled that OK.) I've sometimes seen machine-generated filenames with
\r
132 > double slashes because that way you don't have to make sure the incoming
\r
133 > filename was correctly terminated before adding another level.
\r
135 Nothing outside notmuch (i.e. other applications creating arbitrary
\r
136 filenames etc) can make notmuch store a // as part of a path so if we
\r
137 ever do store them in the database it's our own fault. In particular
\r
138 notmuch can avoid them easily in that they cannot occur in a filename.
\r
141 >> Secondly, I would prefer to keep maildirs as just the bare file name: so
\r
142 >> the existence of // can be the signal that there is some other
\r
143 >> scheme. This is asymmetric, but is rather more backwardly compatible.
\r
146 > Based on your and Jani's reasoning, I did this. Revised patch series
\r
149 I will try and look at that now.
\r