df/7a6e87de9fe777cf6f164610c9548fe5eb15c3

   1 Return-Path: <dkg@fifthhorseman.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id 873636DE01F7\r
   6  for <notmuch@notmuchmail.org>; Sat,  4 Jun 2016 09:23:38 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.07\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=-0.070]\r
  12  autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id WTfEBjGKoInB for <notmuch@notmuchmail.org>;\r
  16  Sat,  4 Jun 2016 09:23:30 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 830476DE00DA\r
  19  for <notmuch@notmuchmail.org>; Sat,  4 Jun 2016 09:23:30 -0700 (PDT)\r
  20 Received: from fifthhorseman.net (h-67-100-110-71.nycm.ny.dynamic.megapath.net\r
  21  [67.100.110.71])\r
  22  by che.mayfirst.org (Postfix) with ESMTPSA id B2ED6F98B;\r
  23  Sat,  4 Jun 2016 12:23:27 -0400 (EDT)\r
  24 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
  25  id 0E180201E6; Sat,  4 Jun 2016 12:23:27 -0400 (EDT)\r
  26 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  27 To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
  28 Subject: Re: [RFC2 Patch 5/5] lib: iterator API for message properties\r
  29 In-Reply-To: <87mvn1euiz.fsf@zancas.localnet>\r
  30 References: <1463927339-5441-1-git-send-email-david@tethera.net>\r
  31  <1464608999-14774-1-git-send-email-david@tethera.net>\r
  32  <1464608999-14774-6-git-send-email-david@tethera.net>\r
  33  <8760tthfuy.fsf@zancas.localnet> <87pos1u14p.fsf@alice.fifthhorseman.net>\r
  34  <87eg8ht2sb.fsf@alice.fifthhorseman.net> <87lh2ofpxk.fsf@zancas.localnet>\r
  35  <87inxrqyv1.fsf@alice.fifthhorseman.net> <8737oufn6f.fsf@zancas.localnet>\r
  36  <87y46mpcbf.fsf@alice.fifthhorseman.net> <87mvn1euiz.fsf@zancas.localnet>\r
  37 User-Agent: Notmuch/0.22+47~g4441900 (http://notmuchmail.org) Emacs/24.5.1\r
  38  (x86_64-pc-linux-gnu)\r
  39 Date: Sat, 04 Jun 2016 12:23:23 -0400\r
  40 Message-ID: <874m98gbyc.fsf@alice.fifthhorseman.net>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: multipart/signed; boundary="=-=-=";\r
  43  micalg=pgp-sha512; protocol="application/pgp-signature"\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.20\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48  <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  50  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Sat, 04 Jun 2016 16:23:38 -0000\r
  57 \r
  58 --=-=-=\r
  59 Content-Type: text/plain\r
  60 \r
  61 On Fri 2016-06-03 19:12:52 -0400, David Bremner wrote:\r
  62 >>> [ dkg wrote: ]\r
  63 >>>>  * for messages which have multiple files, which file is actually indexed\r
  64 >>>\r
  65 >>> yes. Although rather than storing that, I think the right answer is more\r
  66 >>> like "all of them".\r
  67 >>\r
  68 >> I don't think we do this, do we?  Is this a bug?  is it tracked somewhere?\r
  69 >\r
  70 > IMHO it is a bug. It's implicit in\r
  71 >\r
  72 >    id:87k42vrqve.fsf@pip.fifthhorseman.net\r
  73 >\r
  74 > and the various requests for List-Id indexing, but it's probably worth\r
  75 > starting a seperate thread to track it.  Especially since there are some\r
  76 > unresolved design issues. Like what to return for searches.\r
  77 \r
  78 I'm happy to use that original thread from 2012 as the tracking thread\r
  79 if you think that's a reasonable starting point.  Peter Wang's "Malice\r
  80 has nothing on incompetence" message in that thread is a good reminder\r
  81 about other issues there.\r
  82 \r
  83 >> the thread-id is *not* reproducible from the\r
  84 >> message sets.  This is not only because of the ghost message leakage bug\r
  85 >> documented in T590-thread-breakage.sh, but also because threads can be\r
  86 >> joined by a message that is later removed (e.g., the "notmuch-join"\r
  87 >> script in id:87egabu5ta.fsf@alice.fifthhorseman.net ).\r
  88 >\r
  89 > I see, I guess that's the intended behaviour given 604d1e0977c.\r
  90 >\r
  91 > I haven't thought about the pros and cons of dumping/restoring\r
  92 > thread-ids. At least my database has about half as many threads as\r
  93 > messages, so it's a bit of data, but perhaps that's not a bit problem.\r
  94 > It's somewhat orthogonal to this series since those terms are already\r
  95 > attached to messages.\r
  96 \r
  97 i agree that thread restoration is orthogonal to the per-message\r
  98 properties.  I should also be clear that i don't mean to suggest that we\r
  99 should dump the literal thread-id.  That'd be terrible, because you\r
 100 wouldn't be able to merge two databases.\r
 101 \r
 102 I'm happy to move the thread-id discussion to a separate topic, i just\r
 103 want to make sure that people are aware that our current documentation\r
 104 for notmuch-dump (below) kind of overstates the case:\r
 105 \r
 106 ------\r
 107        These tags are the only data in the  notmuch  database  that  can't  be\r
 108        recreated  from  the messages themselves. The output of notmuch dump is\r
 109        therefore the only critical thing to backup (and much more friendly  to\r
 110        incremental backup than the native database files.)\r
 111 ------\r
 112 \r
 113 OK, back to the discussion of per-message properties: i think we should\r
 114 go ahead with this work, now that i understand the scoping/framing of it\r
 115 better!\r
 116 \r
 117       --dkg\r
 118 \r
 119 --=-=-=\r
 120 Content-Type: application/pgp-signature; name="signature.asc"\r
 121 \r
 122 -----BEGIN PGP SIGNATURE-----\r
 123 Version: GnuPG v2\r
 124 \r
 125 iQJ8BAEBCgBmBQJXUwB7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 126 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
 127 NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKx+EQAKfJcsVNv30mIslw5d3GFJkF\r
 128 66yZwn3QsEfkyR7FRAbAwI+N5Hn1oJl90HXrVML83CHXHB4OrgbgYrFOvWwJRPJr\r
 129 ZnCYpTxn+yiDzN6Nbz3psTKIs/KNxAK3P+khMAFYCEvlgLpkk1hor+g7AkPryQBv\r
 130 p4QDZt97eJkqCncOE/Tz/LZGFUU2QOaBDXLktRcwpv4VD6mcpW04t76ISF7uneKw\r
 131 4VoJrmWumFRWbge5V1Wl1EPiwg376fH3c3K26cg9nRT2BfAmPr/8eY69z+JWyCSz\r
 132 qv2AdOSZxtbaJ9uUT1VLsKRWZbfaO/LZekZ+UKEIjQ6YXOt8MTSuFRYn3Vnt6cqO\r
 133 M+rJ8IVkbFxXq8Tx5PSHzuUQlXzRYBcVpGP3wTkn0t6eji73fGocPsJrWL1dcHr0\r
 134 6C1Y5ml7LtKgPhGAeZ1JFCVbKnZo9t3ZFxOG0xlWjJ9JNBVRE2a++cUDWbZQYqhv\r
 135 uUqrHhyNSF/qaj5uQLPTMkVqKTh1oNkBC4QqJWcB8P5Xig/iRCrJfHOynilvH9qW\r
 136 CCK5m1wROMB6e+HAqkoqYErybkOGLMBY96/fq3DFM6d7kltpbiRCM26kiXb9+pB5\r
 137 Sk2/c65uIrCpI6aEAZdDxbHZg1oLEow1c1HaEXyhzULurkrEQuzwC3pjE8vBxS/d\r
 138 dumg/V0aZEkwxm7ZUWUL\r
 139 =bhXV\r
 140 -----END PGP SIGNATURE-----\r
 141 --=-=-=--\r