73/e88079cf014e46127726f44e3a73d1bd3cbeb8

   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 D9A13429E43\r
   6         for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:55:12 -0800 (PST)\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 jRLo6koOlDAn for <notmuch@notmuchmail.org>;\r
  17         Wed, 15 Feb 2012 16:55:09 -0800 (PST)\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 DC0F9429E42\r
  22         for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:55:08 -0800 (PST)\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 1Rxpck-0006NZ-57; Thu, 16 Feb 2012 00:55:06 +0000\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 1Rxpcj-0005A4-PY; Thu, 16 Feb 2012 00:55:02 +0000\r
  32 From: Mark Walters <markwalters1009@gmail.com>\r
  33 To: Ethan Glasser-Camp <glasse@cs.rpi.edu>, notmuch@notmuchmail.org\r
  34 Subject: Re: [RFC PATCH 00/13] Modular message store code\r
  35 In-Reply-To: <1329343326-16410-1-git-send-email-glasse@cs.rpi.edu>\r
  36 References: <1329343326-16410-1-git-send-email-glasse@cs.rpi.edu>\r
  37 User-Agent: Notmuch/0.11.1+206~g3b67774 (http://notmuchmail.org) Emacs/23.2.1\r
  38         (i486-pc-linux-gnu)\r
  39 Date: Thu, 16 Feb 2012 00:56:27 +0000\r
  40 Message-ID: <87y5s3k344.fsf@qmul.ac.uk>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: text/plain; charset=us-ascii\r
  43 X-Sender-Host-Address: 94.192.233.223\r
  44 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  45 X-QM-Body-MD5: 6930044a176351363e975fd3432bcbca (of first 20000 bytes)\r
  46 X-SpamAssassin-Score: -1.8\r
  47 X-SpamAssassin-SpamBar: -\r
  48 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  49         determine if it is\r
  50         spam. We require at least 5.0 points to mark a message as spam.\r
  51         This message scored -1.8 points.\r
  52         Summary of the scoring: \r
  53         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
  54         *      medium trust\r
  55         *      [138.37.6.40 listed in list.dnswl.org]\r
  56         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  57         provider *      (markwalters1009[at]gmail.com)\r
  58         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
  59         *      domain\r
  60         *  0.5 AWL AWL: From: address is in the auto white-list\r
  61 X-QM-Scan-Virus: ClamAV says the message is clean\r
  62 X-BeenThere: notmuch@notmuchmail.org\r
  63 X-Mailman-Version: 2.1.13\r
  64 Precedence: list\r
  65 List-Id: "Use and development of the notmuch mail system."\r
  66         <notmuch.notmuchmail.org>\r
  67 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  69 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  70 List-Post: <mailto:notmuch@notmuchmail.org>\r
  71 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  72 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  73         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  74 X-List-Received-Date: Thu, 16 Feb 2012 00:55:13 -0000\r
  75 \r
  76 On Wed, 15 Feb 2012 17:01:53 -0500, Ethan Glasser-Camp <glasse@cs.rpi.edu> wrote:\r
  77 > Hi guys,\r
  78 > \r
  79 > I'm submitting as RFC this patch series, which introduces the idea of\r
  80 > a "mailstore", a "class" that defines how to access mail, instead of\r
  81 > currently assuming it's always some Maildir-ish hierarchy that\r
  82 > contains a bunch of mail.\r
  83 > \r
  84 > This was listed as a wishlist item on\r
  85 > http://notmuchmail.org/feature-requests/, so I went ahead and took a\r
  86 > crack at it, learning a lot about the codebase as I did. I'm sure\r
  87 > there are tons of stylistic concerns so I'd like to get as much\r
  88 > feedback as possible, starting of course with "Does a feature like\r
  89 > this have a chance of ever making it in" and followed by "Am I on the\r
  90 > right track".\r
  91 > \r
  92 > Note that this series breaks the language bundings; the Python\r
  93 > bindings have very minimal tests so I very minimally fixed them\r
  94 > (probably still broken in other ways), but the Ruby and Go bindings\r
  95 > are probably super broken. Note also that the one message = one file\r
  96 > approach is pretty thoroughly embedded into Notmuch and there are lots\r
  97 > of places (again such as the Python bindings) where this has yet to be\r
  98 > rooted out.\r
  99 > \r
 100 > They say an interface isn't trustworthy until you've implemented it\r
 101 > three times, so while most of the patches define the interface, the\r
 102 > last patch adds support for an experimental CouchDB backend. It's got\r
 103 > at least one known bug (it indexes everything, whether or not it's a\r
 104 > mail object), sometimes it hangs when trying to access a message, and\r
 105 > it's definitely leaking memory in notmuch-new. I haven't done strict\r
 106 > timing comparisons but it seems like notmuch-search and notmuch-show\r
 107 > are approximately as fast as with maildir and notmuch-new takes maybe\r
 108 > 25% longer. Nevertheless, it is included as a demonstration that the\r
 109 > interface is at least plausible.\r
 110 > \r
 111 > The implementation of "mailstores" follows these principles:\r
 112 > \r
 113 > - Messages still have "filenames", but the mailstore gets to define\r
 114 > its own semantics for these filenames (document ids, file + byte\r
 115 > offset..). _notmuch_message_ensure_filename_list converts all\r
 116 > filenames coming out of the DB to be absolute paths centered at the\r
 117 > user's database path, which is inconvenient for Couchdb, but workable.\r
 118 \r
 119 Obviously I have not looked at the patch set in detail yet but I have a\r
 120 quick question. Since you are allowing more general filenames anyway\r
 121 couldn't you encode mailstore in filename? Eg\r
 122 mbox://some-path[:byte-postion], or "imap://server..."\r
 123 \r
 124 This would allow lots of different types of mailstore to be used\r
 125 concurrently, and would push all the mailstore knowledge down into the\r
 126 file handling functions and away from the callers of file handling\r
 127 functions.\r
 128 \r
 129 Of course there may be lots of good reasons why this doesn't work.\r
 130 \r
 131 Best wishes\r
 132 \r
 133 Mark\r
 134 \r
 135 > - The user keeps all mail in one mailstore. The alternative, which is\r
 136 > that each message can be in a different mailstore, seemed like a lot\r
 137 > more work. "One mailstore" makes sense when it's cases like maildir\r
 138 > vs. couchdb, but if we decide to introduce a "mbox" backend --\r
 139 > directory tree with mbox files -- then it might "overlap" with the\r
 140 > maildir mailstore, and then who knows?\r
 141 \r
 142 \r
 143 > \r
 144 > Patch 1 introduces the configuration parameter database.type, which\r
 145 > will be used to select a mailstore type.\r
 146 > \r
 147 > Patch 2 introduces the most important API for a mailstore, notmuch_mailstore_open, and makes it required when creating a message_file. Patch 3 fixes the Python breakage this creates.\r
 148 > \r
 149 > Patch 4-6 replace the other places where files are opened directly with calls to notmuch_mailstore_open.\r
 150 > \r
 151 > Patch 7-8 prepare notmuch-new to be more generic. I couldn't find an elegant way to combine add_files logic with other mailstores, so I just decided each mailstore should have its own add_files function.\r
 152 > \r
 153 > Patches 9-11 add other functions to the mailstore API -- to rename files, to close files, and to "construct" a mailstore. Patch 12 uses the "close" API to close files (where necessary).\r
 154 > \r
 155 > Patch 13 proposes the CouchDB mailstore as one block of code.\r
 156 > \r
 157 > Points to address:\r
 158 > \r
 159 > - Where to put the new notmuch_mailstore_t* parameter in all these functions? I applied a "decreasing order of importance" heuristic, but it's a little weird in places like notmuch_database_open and notmuch_database_create.\r
 160 > \r
 161 > - Is there a better, more elegant way to pass around mailstore objects without adding parameters to each function? Additionally, should I be using some other class-like mechanism for mailstores instead of hacks involving structs?\r
 162 > \r
 163 > - Should this be configured under [database] or perhaps under some other new heading?\r
 164 > \r
 165 > - How strict is the rule that braces shouldn't be there if the body of a loop/conditional is only one line? This feels really strange to me coming from Python.\r
 166 > \r
 167 > - If I'm already touching code, should I add other drive-by fixes, as in patch 05, or should I resolutely refuse to change anything, as in patch 07?\r
 168 > \r
 169 > - Should something like the CouchDB backend be optional, and if so, what mechanisms do I need to use to make that happen?\r
 170 > \r
 171 > Thanks so much for your time!\r
 172 > Ethan\r
 173 > \r
 174 > _______________________________________________\r
 175 > notmuch mailing list\r
 176 > notmuch@notmuchmail.org\r
 177 > http://notmuchmail.org/mailman/listinfo/notmuch\r