0d/c14d24b4b58aa3e94764d9399b58280c74a90f

   1 Return-Path: <cworth@cworth.org>\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 olra.theworths.org (Postfix) with ESMTP id 197C1431FC0;\r
   6         Fri, 18 Dec 2009 11:41:20 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id iEr14TekMYht; Fri, 18 Dec 2009 11:41:19 -0800 (PST)\r
  11 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id 108B1431FAE;\r
  13         Fri, 18 Dec 2009 11:41:19 -0800 (PST)\r
  14 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  15         id 3C7EE254306; Fri, 18 Dec 2009 11:41:19 -0800 (PST)\r
  16 From: Carl Worth <cworth@cworth.org>\r
  17 To: James Westby <jw+debian@jameswestby.net>, notmuch@notmuchmail.org\r
  18 In-Reply-To: <87oclwrtqa.fsf@jameswestby.net>\r
  19 References: <87oclwrtqa.fsf@jameswestby.net>\r
  20 Date: Fri, 18 Dec 2009 11:41:18 -0800\r
  21 Message-ID: <874onoysrl.fsf@yoom.home.cworth.org>\r
  22 MIME-Version: 1.0\r
  23 Content-Type: multipart/signed; boundary="=-=-=";\r
  24         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  25 Subject: Re: [notmuch] Missing messages breaking threads\r
  26 X-BeenThere: notmuch@notmuchmail.org\r
  27 X-Mailman-Version: 2.1.12\r
  28 Precedence: list\r
  29 List-Id: "Use and development of the notmuch mail system."\r
  30         <notmuch.notmuchmail.org>\r
  31 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  32         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  33 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  34 List-Post: <mailto:notmuch@notmuchmail.org>\r
  35 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  36 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  37         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  38 X-List-Received-Date: Fri, 18 Dec 2009 19:41:20 -0000\r
  39 \r
  40 --=-=-=\r
  41 Content-Transfer-Encoding: quoted-printable\r
  42 \r
  43 On Fri, 18 Dec 2009 19:02:21 +0000, James Westby <jw+debian@jameswestby.net=\r
  44 > wrote:\r
  45 > I like the architecture of notmuch, and have just switched\r
  46 > to using it as my primary client, so thanks.\r
  47 \r
  48 You're quite welcome, James. Welcome to notmuch!\r
  49 \r
  50 > Therefore I'd like to fix this. The obvious way is to\r
  51 > introduce documents in to the db for each id we see, and\r
  52 > threading should then naturally work better.\r
  53 \r
  54 That sounds like a fine idea.\r
  55 \r
  56 > The only issue I see with doing this is with mail delays.\r
  57 > Once we do this we will sometimes receive a message that\r
  58 > already has a dummy document. What happens currently with\r
  59 > message-id collisions?\r
  60 \r
  61 The current message-ID collision logic is pretty brain-dead. It just\r
  62 says "Oh, I've seen a file with this message before, so I'll skip this\r
  63 additional file".\r
  64 \r
  65 But I'm just putting the finishing touches on a patch that instead does:\r
  66 \r
  67         Oh, and here's an additional filename for that message ID. Add\r
  68         that too, please.\r
  69 \r
  70 Beyond that, all we would need to do as well is to also index the new\r
  71 content. I don't want to do useless re-indexing when files just get\r
  72 renamed. So maybe all we need to do is to save the filesize of the\r
  73 last-indexed file for a document and then when we encounter a file with\r
  74 the same message ID and a larger file size, then index it as well?\r
  75 \r
  76 That would even take care of providing the opportunity to index\r
  77 additional mailing-list-added content for messages also sent directly\r
  78 via CC.\r
  79 \r
  80 The file-size heuristic wouldn't be perfect for these other cases. I\r
  81 guess we save a list of sha-1 sums for indexed files or so, (assuming\r
  82 that's cheaper than just re-indexing---before the Xapian Defect 250 fix\r
  83 I'm sure it is, but after I'm not sure---we maybe should just always\r
  84 re-index---but I think I have seen the TermGenerator appear in profiles\r
  85 of indexing runs.)\r
  86 \r
  87 >   * When we get a message-id conflict check for dummy:True\r
  88 >     and replace the document if it is there.\r
  89 >=20\r
  90 > How does this sound?\r
  91 \r
  92 That sounds fine. It's the same as what I propose above with\r
  93 "filesize:0" instead of "dummy:true".\r
  94 \r
  95 > There could be an issue with synthesising too many threads\r
  96 > and then ending up having to try and put a message in two\r
  97 > threads? I see there is code for merging threads, would that\r
  98 > handle this?\r
  99 \r
 100 It should, yes.\r
 101 \r
 102 The current logic is that a message can only appear in a single\r
 103 thread. So if a message has children or parents with distinct thread IDs\r
 104 then those threads are merged.\r
 105 \r
 106 I can imagine some strange cross-posting scenario where one could argue\r
 107 that the merging shouldn't happen, but I'm not sure we want to try to\r
 108 respect that.\r
 109 \r
 110 =2DCarl\r
 111 \r
 112 --=-=-=\r
 113 Content-Type: application/pgp-signature\r
 114 \r
 115 -----BEGIN PGP SIGNATURE-----\r
 116 Version: GnuPG v1.4.10 (GNU/Linux)\r
 117 \r
 118 iD8DBQFLK9rf6JDdNq8qSWgRAsEOAJ46ZZge6u1bb3kjJEvP+2Y0GIdSmQCeMLZz\r
 119 kyq2cq6LrJ4Q4UAuaBn2Fac=\r
 120 =Isxu\r
 121 -----END PGP SIGNATURE-----\r
 122 --=-=-=--\r