Re: [RFC2 Patch 5/5] lib: iterator API for message properties
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Wed, 1 Jun 2016 01:52:06 +0000 (21:52 +2000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:21:55 +0000 (16:21 -0700)
0c/350d59a11998de600d126c906c886b127bd9e3 [new file with mode: 0644]

diff --git a/0c/350d59a11998de600d126c906c886b127bd9e3 b/0c/350d59a11998de600d126c906c886b127bd9e3
new file mode 100644 (file)
index 0000000..638d5c2
--- /dev/null
@@ -0,0 +1,120 @@
+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 B76606DE02A9\r
+ for <notmuch@notmuchmail.org>; Tue, 31 May 2016 18:58:33 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.024\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5\r
+ tests=[AWL=-0.024] 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 vz06-e1gT_zD for <notmuch@notmuchmail.org>;\r
+ Tue, 31 May 2016 18:58:25 -0700 (PDT)\r
+X-Greylist: delayed 375 seconds by postgrey-1.35 at arlo;\r
+ Tue, 31 May 2016 18:58:24 PDT\r
+Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
+ by arlo.cworth.org (Postfix) with ESMTP id EE5E96DE02A6\r
+ for <notmuch@notmuchmail.org>; Tue, 31 May 2016 18:58:24 -0700 (PDT)\r
+Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net\r
+ [108.58.6.98])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id 89664F98B;\r
+ Tue, 31 May 2016 21:52:06 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id 60159201E6; Tue, 31 May 2016 21:52:06 -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: <8760tthfuy.fsf@zancas.localnet>\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>\r
+User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Tue, 31 May 2016 21:52:06 -0400\r
+Message-ID: <87pos1u14p.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 01:58:33 -0000\r
+\r
+On Tue 2016-05-31 21:12:21 -0400, David Bremner <david@tethera.net> wrote:\r
+> I was thinking a bit about how to dump/restore these.\r
+>\r
+> The most upwardly compatible way that i thought of is something like\r
+>\r
+> #= msg-id key=val key=val\r
+>\r
+> i.e. duplicate the msg-id for messages with properties\r
+>\r
+> This would be ignored by old notmuch-restore.\r
+>\r
+> Otherwise, maybe something like\r
+>\r
+> msg-id -- +tag +tag # key=val key=val\r
+>\r
+> I'm not sure. this might crash old notmuch-restore.\r
+>\r
+> How important is backward compatibility, and how important is minimizing\r
+> dump size? It's a bit hard to predict the things people might use\r
+> message properties for, but for thread surgery, I would expect a small\r
+> number of messages with properties.\r
+\r
+The other concern is our conception of how properties are unset/removed,\r
+right?\r
+\r
+With tags, it's possible to include -blah to remove the tag "blah".  how\r
+do we remove/clear/overwrite these tags?  what about using +key=val or\r
+-key=val to set/unset certain key/value combinations, and a value-less\r
+key= to remove all values matching a given key?\r
+\r
+alternately:\r
+\r
+ key=val (clears all values for "key", and sets a new value "val")\r
+ key+=val (appends a value "val" for "key")\r
+ key-=val (removes any "key" set to "val")\r
+ key= (clears all values for "key"\r
+\r
+---------\r
+\r
+However we resolve this particular decision, it'd be nice to have a\r
+stable, sane story about backward compatibility going forward, so that\r
+we don't have to worry about it in the future.\r
+\r
+For example, each dump file could start with a line like:\r
+\r
+  #version 1\r
+\r
+and notmuch restore would assume that without "#version n" as the first\r
+line, it's version 0.  then notmuch restore could decline to parse dump\r
+files of a version that it doesn't know about.\r
+\r
+Alternately, we could have the first line be something like:\r
+\r
+   #features config properties\r
+\r
+and if the first line is not #features, then we assume that no features\r
+are in place -- but if restore sees features it doesn't know about, it\r
+can offer to proceed while warning the user that we might miss something\r
+(or that something might break).\r
+\r
+\r
+Thanks for working on this, David!  I think this is going to be really\r
+useful!\r
+\r
+    --dkg\r