Re: [RFC2 Patch 5/5] lib: iterator API for message properties

diff --git a/ad/aac34780c41323c5193173e880569f66b19521 b/ad/aac34780c41323c5193173e880569f66b19521
new file mode 100644 (file)
index 0000000..9edf00a
--- /dev/null
+++ b/ad/aac34780c41323c5193173e880569f66b19521
@@ -0,0 +1,88 @@
+Return-Path: <dkg@fifthhorseman.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 156C26DE0243\r
+ for <notmuch@notmuchmail.org>; Wed,  1 Jun 2016 07:14:10 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.018\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5\r
+ tests=[AWL=-0.018] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id Tj5EsRK_gCD4 for <notmuch@notmuchmail.org>;\r
+ Wed,  1 Jun 2016 07:14:02 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 22DBA6DE01D0\r
+ for <notmuch@notmuchmail.org>; Wed,  1 Jun 2016 07:14:02 -0700 (PDT)\r
+Received: from fifthhorseman.net (unknown [38.109.115.130])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id 48C73F98B;\r
+ Wed,  1 Jun 2016 10:13:57 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id 0808D2022D; Wed,  1 Jun 2016 10:13:57 -0400 (EDT)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC2 Patch 5/5] lib: iterator API for message properties\r
+In-Reply-To: <87pos1u14p.fsf@alice.fifthhorseman.net>\r
+References: <1463927339-5441-1-git-send-email-david@tethera.net>\r
+ <1464608999-14774-1-git-send-email-david@tethera.net>\r
+ <1464608999-14774-6-git-send-email-david@tethera.net>\r
+ <8760tthfuy.fsf@zancas.localnet> <87pos1u14p.fsf@alice.fifthhorseman.net>\r
+User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Wed, 01 Jun 2016 10:13:56 -0400\r
+Message-ID: <87eg8ht2sb.fsf@alice.fifthhorseman.net>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 01 Jun 2016 14:14:10 -0000\r
+\r
+On Tue 2016-05-31 21:52:06 -0400, Daniel Kahn Gillmor wrote:\r
+> Thanks for working on this, David!  I think this is going to be really\r
+> useful!\r
+\r
+just thinking about this series this morning in a bigger-picture way, i\r
+figure it's worth asking the hard questions now rather than later --\r
+maybe the answers are obvious, and we just need to write them down.\r
+Please accept these questions in the spirit of supportive inquiry :)\r
+Here goes:\r
+\r
+do we actually need this abstraction?  If we're aiming to build specific\r
+new features (the two i'm thinking of are cryptographic-session-keys and\r
+reference-adjustments), couldn't we implement those features explicitly\r
+in xapian with their own special prefix, rather than treating them as a\r
+generic "property"?  If we make a generic "property", that seems likely\r
+to be exposed to the user, who can then manipulate them directly\r
+externally from notmuch.\r
+\r
+We already have a bit of an uncomfortable fit with tags and special\r
+flags (encrypted, signed, attachment, etc), where some are expected to\r
+be set and cleared automagically and some are expected to be manipulated\r
+directly by the user.  Are we setting ourselves up for more of the same,\r
+or is there a principled way that a user can know which properties it's\r
+kosher for them to set and clear, and which ones they should leave\r
+alone?\r
+\r
+If we add new specific features, we could potentially augment the dump\r
+format explicitly for them, without having the property abstraction.  We\r
+already have some explicit features for each message (subject, from, to,\r
+attachment, mimetype, thread id, etc), and most of them are derived from\r
+the message itself, with the hope that it could be re-derived given just\r
+the message body.  Is there a distinction between properties that can be\r
+derived from the message body and properties that need to be\r
+additionally derived from some other data?\r
+\r
+   --dkg\r