Re: [RFC2 Patch 5/5] lib: iterator API for message properties
authorDavid Bremner <david@tethera.net>
Fri, 3 Jun 2016 12:54:00 +0000 (09:54 +2100)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:21:57 +0000 (16:21 -0700)
cf/aa06868a913fe66a5700fe85524ebb7f2c1177 [new file with mode: 0644]

diff --git a/cf/aa06868a913fe66a5700fe85524ebb7f2c1177 b/cf/aa06868a913fe66a5700fe85524ebb7f2c1177
new file mode 100644 (file)
index 0000000..fa7817d
--- /dev/null
@@ -0,0 +1,125 @@
+Return-Path: <david@tethera.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 97C9E6DE00DB\r
+ for <notmuch@notmuchmail.org>; Fri,  3 Jun 2016 05:55:07 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.012\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5\r
+ tests=[AWL=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
+ 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 RCqoBAeEX32t for <notmuch@notmuchmail.org>;\r
+ Fri,  3 Jun 2016 05:54:59 -0700 (PDT)\r
+Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id 8FA876DE02A6\r
+ for <notmuch@notmuchmail.org>; Fri,  3 Jun 2016 05:54:13 -0700 (PDT)\r
+Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
+ (envelope-from <david@tethera.net>)\r
+ id 1b8obu-0004BK-S1; Fri, 03 Jun 2016 08:53:58 -0400\r
+Received: (nullmailer pid 4516 invoked by uid 1000);\r
+ Fri, 03 Jun 2016 12:54:08 -0000\r
+From: David Bremner <david@tethera.net>\r
+To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC2 Patch 5/5] lib: iterator API for message properties\r
+In-Reply-To: <87inxrqyv1.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
+ <87eg8ht2sb.fsf@alice.fifthhorseman.net> <87lh2ofpxk.fsf@zancas.localnet>\r
+ <87inxrqyv1.fsf@alice.fifthhorseman.net>\r
+User-Agent: Notmuch/0.22+28~gb9bf3f4 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Fri, 03 Jun 2016 09:54:00 -0300\r
+Message-ID: <8737oufn6f.fsf@zancas.localnet>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha256; protocol="application/pgp-signature"\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: Fri, 03 Jun 2016 12:55:07 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+\r
+Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
+\r
+>\r
+> I think this makes sense, and makes me more comfortable with the overall\r
+> idea of this patch series.  maybe it'd be useful to clearly document the\r
+> intended scope?\r
+>\r
+\r
+Sure, where do you think that kind of documentation is appropriate?\r
+There is the giant comment about the database schema in\r
+lib/database.cc. Actually I just noticed I already failed to update that\r
+for libconfig stuff.\r
+>\r
+> From elsewhere:\r
+>\r
+>  * for messages which have multiple files, which file is actually indexed\r
+\r
+yes. Although rather than storing that, I think the right answer is more\r
+like "all of them".\r
+\r
+>  * thread-id\r
+>  * tag\r
+>\r
+> we're now talking about adding properties, which are in the "elsewhere"\r
+> category, right?\r
+\r
+Correct.\r
+\r
+>\r
+> It's worth noticing that the stuff in "elsewhere" is the stuff that\r
+> won't propagate across a dump/restore unless it's explicitly in the dump\r
+> somehow.   We currently fail to restore thread-id and which file is\r
+> actually indexed across a dump/restore :/\r
+\r
+The thread-id is in some sense derived from the message itself. Not in a\r
+reproducable way, but still, the dump file is the minimal set of extra\r
+data needed to reconstruct an equivalent database (pax threading bugs).\r
+\r
+> I think you've convinced me that it's good to go ahead with the\r
+> properties, assuming it's scoped as defined above.  I still think that\r
+> we need a better story for upgrades to the dump format in general, but\r
+> maybe this isn't the place to make that particular case.\r
+>\r
+>             --dkg\r
+\r
+I'm not sure what you have in mind, something more ambitious than the\r
+header added post 0.22?\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1\r
+\r
+iQGcBAEBCAAGBQJXUX3pAAoJEPIClx2kp54sHwgL/3mH0iM4myE4hF6a7N4dgRJZ\r
+pHBSKknIlHU+5GJUc9gztdjKfTQZk/lUqPsW8ibh9hGzWyWvrsqZcSvlQr1tGnCD\r
+bx6K6qO4ES4hSDlysyiyCje/XKuFLGi9mD09DRxJjSL+Rlezy9SoLTiqG/JIhoB8\r
+6Q6pF1etof4l/ysm99+9u5ITO9gW3cc4x6xQpLPjeNLkFrmFfG9RBT/bsDhe2jq7\r
+Fyan4uXWCXICuTxnBP5uYrc1UMJPmaczxkEOPKCD9Af52o8sQIm74uYdUNYHuJIR\r
+0R+xMlQJX415WhMrjvnnCNpuWDQOZHKF2R68Dp4QXbIzTK05uPcKoBGAI7BE25Y4\r
+Vv1UefIyWp8s4KGbpLJRdbbu4eycqobT3WL9XwCtzrm58fyOu0g06YksKxrvjIN3\r
+yZm4/SvzUaD9JlfJOjRxNGSxKErRBNEYTtOo0ZXT1BOy2tG6jltU6YlcGghEcTmX\r
+x+/p/C7nQS6bfy4jqvYmnDDSq/uD28sHbmUYRlxtaQ==\r
+=RGB8\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r