d7/37796577b4d5daf5f338fd5c55921ee38ace39

   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 476BC431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu, 28 Jun 2012 13:45:34 -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: -1.098\r
  10 X-Spam-Level: \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 wqxEs8BdWwyg for <notmuch@notmuchmail.org>;\r
  17         Thu, 28 Jun 2012 13:45:33 -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 6E9B6431FAF\r
  22         for <notmuch@notmuchmail.org>; Thu, 28 Jun 2012 13:45:33 -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 1SkLae-0001AU-EN; Thu, 28 Jun 2012 21:45:29 +0100\r
  27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
  28         helo=localhost)\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 1SkLae-0004H0-1Z; Thu, 28 Jun 2012 21:45:24 +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
  35 In-Reply-To:\r
  36  <CAOJ+Ob0Kw0Kkhh9C27Xv9gvqtNowzQiNqrLAtvti7fL8NND2+w@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 User-Agent: Notmuch/0.13.2+63~g548a9bf (http://notmuchmail.org) Emacs/23.4.1\r
  41         (x86_64-pc-linux-gnu)\r
  42 Date: Thu, 28 Jun 2012 21:45:17 +0100\r
  43 Message-ID: <87k3yrmahu.fsf@qmul.ac.uk>\r
  44 MIME-Version: 1.0\r
  45 Content-Type: text/plain; charset=us-ascii\r
  46 X-Sender-Host-Address: 94.192.233.223\r
  47 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  48 X-QM-Body-MD5: 8e222e9d9c98afd4c482bb64b2c82a6f (of first 20000 bytes)\r
  49 X-SpamAssassin-Score: -1.8\r
  50 X-SpamAssassin-SpamBar: -\r
  51 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  52         determine if it is\r
  53         spam. We require at least 5.0 points to mark a message as spam.\r
  54         This message scored -1.8 points.\r
  55         Summary of the scoring: \r
  56         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
  57         *      medium trust\r
  58         *      [138.37.6.40 listed in list.dnswl.org]\r
  59         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  60         provider *      (markwalters1009[at]gmail.com)\r
  61         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
  62         *      domain\r
  63         *  0.5 AWL AWL: From: address is in the auto white-list\r
  64 X-QM-Scan-Virus: ClamAV says the message is clean\r
  65 Cc: notmuch@notmuchmail.org\r
  66 X-BeenThere: notmuch@notmuchmail.org\r
  67 X-Mailman-Version: 2.1.13\r
  68 Precedence: list\r
  69 List-Id: "Use and development of the notmuch mail system."\r
  70         <notmuch.notmuchmail.org>\r
  71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  74 List-Post: <mailto:notmuch@notmuchmail.org>\r
  75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  78 X-List-Received-Date: Thu, 28 Jun 2012 20:45:34 -0000\r
  79 \r
  80 On Thu, 28 Jun 2012, Ethan <ethan.glasser.camp@gmail.com> wrote:\r
  81 > I sent this at first as a reply-only-to-sender. Oops! Sorry Mark for the\r
  82 > double send.\r
  83 >\r
  84 > On Wed, Jun 27, 2012 at 5:17 AM, Mark Walters <markwalters1009@gmail.com>wrote:\r
  85 >\r
  86 >> > Personally, this isn't my favorite approach, for the following reasons:\r
  87 >> >\r
  88 >> > 1. Notmuch, at some point in its history, chose to store file paths\r
  89 >> > relative to a "mail database", with the intent that if this mail\r
  90 >> > database was moved, filenames would not change and everything would\r
  91 >> > Just Work (tm). The above scheme completely reverses this design\r
  92 >> > decision, and in general completely breaks this relocatability. I\r
  93 >> > don't see any easy way to handle this problem. This isn't just a\r
  94 >> > wishlist feature; at least two things in the test suite (caching of\r
  95 >> > corpus.mail, and the atomicity tests) rely on this behavior.\r
  96 >>\r
  97 >> Why can't the URI just store a relative path, at least for maildir://\r
  98 >> and mbox:// ? It is purely internal to notmuch so it doesn't need to be\r
  99 >> very standard.\r
 100 >>\r
 101 >\r
 102 > Well, relative to where? This is especially relevant now that we can have\r
 103 > multiple mail stores. It sounds like you are suggesting that all mbox://\r
 104 > URIs are relative to an "mbox root", but the fundamental question is how to\r
 105 > pass that information from the configuration into the library.\r
 106 \r
 107 I was thinking of just having one mail root and inside that there could\r
 108 be maildirs and mboxes. Everything would still be relative to the root.\r
 109 \r
 110 > Even using configuration itself may be problematic, because only the CLI\r
 111 > uses the configuration, and language bindings like Python and Ruby might\r
 112 > get out of sync! (But note also that the Python bindings currently use\r
 113 > .notmuch-config to find the database path, so maybe it's not a big deal.)\r
 114 >\r
 115 > If I could do whatever I wanted, every mailstore would get registered\r
 116 > somehow and the URIs could use those registered names to specify what\r
 117 > they're relative to: maybe using hostname, such as\r
 118 > maildir://university-mail/some-mail-file, mbox://old-unix-system/some.mbox.\r
 119 > Then changing these names in .notmuch-config would be fine. I just don't\r
 120 > know how to pass that configuration information without an approach like in\r
 121 > the past patch series.\r
 122 >\r
 123 >  > 2. Mail access information, i.e. open connections, etc. can only be\r
 124 >> > stored in variables global to the mailstore code, and cannot be stored\r
 125 >> > as private members of a mailstore object. This is more an aesthetic\r
 126 >> > concern than a functional one.\r
 127 >> >\r
 128 >> > Anyhow, the following (enormous) patch series implement this design. I\r
 129 >> > used uriparser as an external library to parse URIs. The API for this\r
 130 >> > library is a little idiosyncratic. uriparser supports parsing Unicode\r
 131 >> > URIs (strings of wchar_t), but I just used ASCII filenames because I\r
 132 >> > think that's what comes out of Xapian.\r
 133 >>\r
 134 >> Why use a library? Isn't it just a question of does the string contain\r
 135 >> // and, if so, splitting it? I guess that // is a nice separator as I\r
 136 >> think we can assume that a true path does not contain it (since a\r
 137 >> filename cannot contain /).\r
 138 >>\r
 139 >\r
 140 > The URIs are true URIs. Filenames are provided by the "path" segment of the\r
 141 > uri -- everything from the first slash after the hostname up to a ? for\r
 142 > query arguments. My concern was that filenames could (in theory) contain #\r
 143 > or ?, and in practice they contain : (maildir flags). I figured it was\r
 144 > better to do it right.\r
 145 \r
 146 This is similar to your question to Jamie:\r
 147 \r
 148 >  1. Are URIs the way to specify individual messages, despite bremner's\r
 149 >  concerns about too much of the API being strings? Is adding another library\r
 150 >  is the easiest way to parse URIs?\r
 151 \r
 152 In my opinion  the nice thing about using strings is that it does not require\r
 153 any changes to the Xapian database to store them. I think using URIs may\r
 154 not be best though as they seem to be annoying to parse (as filenames\r
 155 can contain the same characters) and you seem to need to work around the\r
 156 parser in some cases.\r
 157 \r
 158 I wonder if the following would be practical: use // as the field\r
 159 separator:\r
 160 \r
 161 e.g. mbox://filename//start_of_message+length\r
 162 \r
 163 I think 2 consecutive slashes // is about the only thing we can assume\r
 164 is not in the path or filename. Since it is not in the filename I think\r
 165 parsing should be trivial (thus avoiding the extra library).\r
 166  \r
 167 Secondly, I would prefer to keep maildirs as just the bare file name: so\r
 168 the existence of // can be the signal that there is some other\r
 169 scheme. This is asymmetric, but is rather more backwardly compatible. \r
 170 \r
 171 I have read most of the patches and will send a couple of specific\r
 172 comments but I completely agree with you that the first thing is to\r
 173 decide the above.\r
 174 \r
 175 Finally do note these are just my views and others may have very\r
 176 different ideas!\r
 177 \r
 178 Best wishes\r
 179 \r
 180 Mark\r
 181 \r