--- /dev/null
+Return-Path: <m.walters@qmul.ac.uk>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id D9A13429E43\r
+ for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:55:12 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.098\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
+ tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
+ NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id jRLo6koOlDAn for <notmuch@notmuchmail.org>;\r
+ Wed, 15 Feb 2012 16:55:09 -0800 (PST)\r
+Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id DC0F9429E42\r
+ for <notmuch@notmuchmail.org>; Wed, 15 Feb 2012 16:55:08 -0800 (PST)\r
+Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
+ by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Rxpck-0006NZ-57; Thu, 16 Feb 2012 00:55:06 +0000\r
+Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
+ helo=localhost)\r
+ by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Rxpcj-0005A4-PY; Thu, 16 Feb 2012 00:55:02 +0000\r
+From: Mark Walters <markwalters1009@gmail.com>\r
+To: Ethan Glasser-Camp <glasse@cs.rpi.edu>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC PATCH 00/13] Modular message store code\r
+In-Reply-To: <1329343326-16410-1-git-send-email-glasse@cs.rpi.edu>\r
+References: <1329343326-16410-1-git-send-email-glasse@cs.rpi.edu>\r
+User-Agent: Notmuch/0.11.1+206~g3b67774 (http://notmuchmail.org) Emacs/23.2.1\r
+ (i486-pc-linux-gnu)\r
+Date: Thu, 16 Feb 2012 00:56:27 +0000\r
+Message-ID: <87y5s3k344.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Sender-Host-Address: 94.192.233.223\r
+X-QM-SPAM-Info: Sender has good ham record. :)\r
+X-QM-Body-MD5: 6930044a176351363e975fd3432bcbca (of first 20000 bytes)\r
+X-SpamAssassin-Score: -1.8\r
+X-SpamAssassin-SpamBar: -\r
+X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
+ determine if it is\r
+ spam. We require at least 5.0 points to mark a message as spam.\r
+ This message scored -1.8 points.\r
+ Summary of the scoring: \r
+ * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
+ * medium trust\r
+ * [138.37.6.40 listed in list.dnswl.org]\r
+ * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
+ provider * (markwalters1009[at]gmail.com)\r
+ * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
+ * domain\r
+ * 0.5 AWL AWL: From: address is in the auto white-list\r
+X-QM-Scan-Virus: ClamAV says the message is clean\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 16 Feb 2012 00:55:13 -0000\r
+\r
+On Wed, 15 Feb 2012 17:01:53 -0500, Ethan Glasser-Camp <glasse@cs.rpi.edu> wrote:\r
+> Hi guys,\r
+> \r
+> I'm submitting as RFC this patch series, which introduces the idea of\r
+> a "mailstore", a "class" that defines how to access mail, instead of\r
+> currently assuming it's always some Maildir-ish hierarchy that\r
+> contains a bunch of mail.\r
+> \r
+> This was listed as a wishlist item on\r
+> http://notmuchmail.org/feature-requests/, so I went ahead and took a\r
+> crack at it, learning a lot about the codebase as I did. I'm sure\r
+> there are tons of stylistic concerns so I'd like to get as much\r
+> feedback as possible, starting of course with "Does a feature like\r
+> this have a chance of ever making it in" and followed by "Am I on the\r
+> right track".\r
+> \r
+> Note that this series breaks the language bundings; the Python\r
+> bindings have very minimal tests so I very minimally fixed them\r
+> (probably still broken in other ways), but the Ruby and Go bindings\r
+> are probably super broken. Note also that the one message = one file\r
+> approach is pretty thoroughly embedded into Notmuch and there are lots\r
+> of places (again such as the Python bindings) where this has yet to be\r
+> rooted out.\r
+> \r
+> They say an interface isn't trustworthy until you've implemented it\r
+> three times, so while most of the patches define the interface, the\r
+> last patch adds support for an experimental CouchDB backend. It's got\r
+> at least one known bug (it indexes everything, whether or not it's a\r
+> mail object), sometimes it hangs when trying to access a message, and\r
+> it's definitely leaking memory in notmuch-new. I haven't done strict\r
+> timing comparisons but it seems like notmuch-search and notmuch-show\r
+> are approximately as fast as with maildir and notmuch-new takes maybe\r
+> 25% longer. Nevertheless, it is included as a demonstration that the\r
+> interface is at least plausible.\r
+> \r
+> The implementation of "mailstores" follows these principles:\r
+> \r
+> - Messages still have "filenames", but the mailstore gets to define\r
+> its own semantics for these filenames (document ids, file + byte\r
+> offset..). _notmuch_message_ensure_filename_list converts all\r
+> filenames coming out of the DB to be absolute paths centered at the\r
+> user's database path, which is inconvenient for Couchdb, but workable.\r
+\r
+Obviously I have not looked at the patch set in detail yet but I have a\r
+quick question. Since you are allowing more general filenames anyway\r
+couldn't you encode mailstore in filename? Eg\r
+mbox://some-path[:byte-postion], or "imap://server..."\r
+\r
+This would allow lots of different types of mailstore to be used\r
+concurrently, and would push all the mailstore knowledge down into the\r
+file handling functions and away from the callers of file handling\r
+functions.\r
+\r
+Of course there may be lots of good reasons why this doesn't work.\r
+\r
+Best wishes\r
+\r
+Mark\r
+\r
+> - The user keeps all mail in one mailstore. The alternative, which is\r
+> that each message can be in a different mailstore, seemed like a lot\r
+> more work. "One mailstore" makes sense when it's cases like maildir\r
+> vs. couchdb, but if we decide to introduce a "mbox" backend --\r
+> directory tree with mbox files -- then it might "overlap" with the\r
+> maildir mailstore, and then who knows?\r
+\r
+\r
+> \r
+> Patch 1 introduces the configuration parameter database.type, which\r
+> will be used to select a mailstore type.\r
+> \r
+> 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
+> \r
+> Patch 4-6 replace the other places where files are opened directly with calls to notmuch_mailstore_open.\r
+> \r
+> 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
+> \r
+> 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
+> \r
+> Patch 13 proposes the CouchDB mailstore as one block of code.\r
+> \r
+> Points to address:\r
+> \r
+> - 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
+> \r
+> - 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
+> \r
+> - Should this be configured under [database] or perhaps under some other new heading?\r
+> \r
+> - 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
+> \r
+> - 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
+> \r
+> - Should something like the CouchDB backend be optional, and if so, what mechanisms do I need to use to make that happen?\r
+> \r
+> Thanks so much for your time!\r
+> Ethan\r
+> \r
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r
projects / notmuch-archives.git / commitdiff