Re: [RFC2 Patch 5/5] lib: iterator API for message properties
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Sat, 4 Jun 2016 16:23:23 +0000 (12:23 +2000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:21:58 +0000 (16:21 -0700)
df/7a6e87de9fe777cf6f164610c9548fe5eb15c3 [new file with mode: 0644]

diff --git a/df/7a6e87de9fe777cf6f164610c9548fe5eb15c3 b/df/7a6e87de9fe777cf6f164610c9548fe5eb15c3
new file mode 100644 (file)
index 0000000..40c14b3
--- /dev/null
@@ -0,0 +1,141 @@
+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 873636DE01F7\r
+ for <notmuch@notmuchmail.org>; Sat,  4 Jun 2016 09:23:38 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.07\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=-0.070]\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 WTfEBjGKoInB for <notmuch@notmuchmail.org>;\r
+ Sat,  4 Jun 2016 09:23:30 -0700 (PDT)\r
+Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 830476DE00DA\r
+ for <notmuch@notmuchmail.org>; Sat,  4 Jun 2016 09:23:30 -0700 (PDT)\r
+Received: from fifthhorseman.net (h-67-100-110-71.nycm.ny.dynamic.megapath.net\r
+ [67.100.110.71])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id B2ED6F98B;\r
+ Sat,  4 Jun 2016 12:23:27 -0400 (EDT)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id 0E180201E6; Sat,  4 Jun 2016 12:23:27 -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: <87mvn1euiz.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> <87pos1u14p.fsf@alice.fifthhorseman.net>\r
+ <87eg8ht2sb.fsf@alice.fifthhorseman.net> <87lh2ofpxk.fsf@zancas.localnet>\r
+ <87inxrqyv1.fsf@alice.fifthhorseman.net> <8737oufn6f.fsf@zancas.localnet>\r
+ <87y46mpcbf.fsf@alice.fifthhorseman.net> <87mvn1euiz.fsf@zancas.localnet>\r
+User-Agent: Notmuch/0.22+47~g4441900 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 04 Jun 2016 12:23:23 -0400\r
+Message-ID: <874m98gbyc.fsf@alice.fifthhorseman.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha512; 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: Sat, 04 Jun 2016 16:23:38 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+\r
+On Fri 2016-06-03 19:12:52 -0400, David Bremner wrote:\r
+>>> [ dkg wrote: ]\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
+>> I don't think we do this, do we?  Is this a bug?  is it tracked somewhere?\r
+>\r
+> IMHO it is a bug. It's implicit in\r
+>\r
+>    id:87k42vrqve.fsf@pip.fifthhorseman.net\r
+>\r
+> and the various requests for List-Id indexing, but it's probably worth\r
+> starting a seperate thread to track it.  Especially since there are some\r
+> unresolved design issues. Like what to return for searches.\r
+\r
+I'm happy to use that original thread from 2012 as the tracking thread\r
+if you think that's a reasonable starting point.  Peter Wang's "Malice\r
+has nothing on incompetence" message in that thread is a good reminder\r
+about other issues there.\r
+\r
+>> the thread-id is *not* reproducible from the\r
+>> message sets.  This is not only because of the ghost message leakage bug\r
+>> documented in T590-thread-breakage.sh, but also because threads can be\r
+>> joined by a message that is later removed (e.g., the "notmuch-join"\r
+>> script in id:87egabu5ta.fsf@alice.fifthhorseman.net ).\r
+>\r
+> I see, I guess that's the intended behaviour given 604d1e0977c.\r
+>\r
+> I haven't thought about the pros and cons of dumping/restoring\r
+> thread-ids. At least my database has about half as many threads as\r
+> messages, so it's a bit of data, but perhaps that's not a bit problem.\r
+> It's somewhat orthogonal to this series since those terms are already\r
+> attached to messages.\r
+\r
+i agree that thread restoration is orthogonal to the per-message\r
+properties.  I should also be clear that i don't mean to suggest that we\r
+should dump the literal thread-id.  That'd be terrible, because you\r
+wouldn't be able to merge two databases.\r
+\r
+I'm happy to move the thread-id discussion to a separate topic, i just\r
+want to make sure that people are aware that our current documentation\r
+for notmuch-dump (below) kind of overstates the case:\r
+\r
+------\r
+       These tags are the only data in the  notmuch  database  that  can't  be\r
+       recreated  from  the messages themselves. The output of notmuch dump is\r
+       therefore the only critical thing to backup (and much more friendly  to\r
+       incremental backup than the native database files.)\r
+------\r
+\r
+OK, back to the discussion of per-message properties: i think we should\r
+go ahead with this work, now that i understand the scoping/framing of it\r
+better!\r
+\r
+      --dkg\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v2\r
+\r
+iQJ8BAEBCgBmBQJXUwB7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
+ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
+NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKx+EQAKfJcsVNv30mIslw5d3GFJkF\r
+66yZwn3QsEfkyR7FRAbAwI+N5Hn1oJl90HXrVML83CHXHB4OrgbgYrFOvWwJRPJr\r
+ZnCYpTxn+yiDzN6Nbz3psTKIs/KNxAK3P+khMAFYCEvlgLpkk1hor+g7AkPryQBv\r
+p4QDZt97eJkqCncOE/Tz/LZGFUU2QOaBDXLktRcwpv4VD6mcpW04t76ISF7uneKw\r
+4VoJrmWumFRWbge5V1Wl1EPiwg376fH3c3K26cg9nRT2BfAmPr/8eY69z+JWyCSz\r
+qv2AdOSZxtbaJ9uUT1VLsKRWZbfaO/LZekZ+UKEIjQ6YXOt8MTSuFRYn3Vnt6cqO\r
+M+rJ8IVkbFxXq8Tx5PSHzuUQlXzRYBcVpGP3wTkn0t6eji73fGocPsJrWL1dcHr0\r
+6C1Y5ml7LtKgPhGAeZ1JFCVbKnZo9t3ZFxOG0xlWjJ9JNBVRE2a++cUDWbZQYqhv\r
+uUqrHhyNSF/qaj5uQLPTMkVqKTh1oNkBC4QqJWcB8P5Xig/iRCrJfHOynilvH9qW\r
+CCK5m1wROMB6e+HAqkoqYErybkOGLMBY96/fq3DFM6d7kltpbiRCM26kiXb9+pB5\r
+Sk2/c65uIrCpI6aEAZdDxbHZg1oLEow1c1HaEXyhzULurkrEQuzwC3pjE8vBxS/d\r
+dumg/V0aZEkwxm7ZUWUL\r
+=bhXV\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r