a4/8c0e320c1a365dbaf3f3955d12d044b5524ab9

   1 Return-Path: <james@jameswestby.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 olra.theworths.org (Postfix) with ESMTP id 2FFC2431FAE\r
   6         for <notmuch@notmuchmail.org>; Fri, 18 Dec 2009 11:02:31 -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 EPAqHHbqLDbF for <notmuch@notmuchmail.org>;\r
  11         Fri, 18 Dec 2009 11:02:30 -0800 (PST)\r
  12 Received: from mout.perfora.net (mout.perfora.net [74.208.4.195])\r
  13         by olra.theworths.org (Postfix) with ESMTP id 6C5F8431FC3\r
  14         for <notmuch@notmuchmail.org>; Fri, 18 Dec 2009 11:02:30 -0800 (PST)\r
  15 Received: from jameswestby.net (jameswestby.net [89.145.97.141])\r
  16         by mx.perfora.net (node=mxus2) with ESMTP (Nemesis)\r
  17         id 0MA8Qr-1NAThE1ykT-00BOWU for notmuch@notmuchmail.org;\r
  18         Fri, 18 Dec 2009 14:02:29 -0500\r
  19 Received: from cpc4-aztw22-2-0-cust59.aztw.cable.virginmedia.com\r
  20         ([94.169.116.60] helo=flash)\r
  21         by jameswestby.net with esmtpa (Exim 4.69)\r
  22         (envelope-from <james@jameswestby.net>) id 1NLi5r-0005oR-5z\r
  23         for notmuch@notmuchmail.org; Fri, 18 Dec 2009 19:02:27 +0000\r
  24 Received: by flash (Postfix, from userid 1000)\r
  25         id 90CFA6E546A; Fri, 18 Dec 2009 19:02:21 +0000 (GMT)\r
  26 From: James Westby <jw+debian@jameswestby.net>\r
  27 To: notmuch@notmuchmail.org\r
  28 Date: Fri, 18 Dec 2009 19:02:21 +0000\r
  29 Message-ID: <87oclwrtqa.fsf@jameswestby.net>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: text/plain; charset=us-ascii\r
  32 Subject: [notmuch] Missing messages breaking threads\r
  33 X-BeenThere: notmuch@notmuchmail.org\r
  34 X-Mailman-Version: 2.1.12\r
  35 Precedence: list\r
  36 List-Id: "Use and development of the notmuch mail system."\r
  37         <notmuch.notmuchmail.org>\r
  38 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  40 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  41 List-Post: <mailto:notmuch@notmuchmail.org>\r
  42 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  43 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  45 X-List-Received-Date: Fri, 18 Dec 2009 19:02:31 -0000\r
  46 \r
  47 Hi,\r
  48 \r
  49 I like the architecture of notmuch, and have just switched\r
  50 to using it as my primary client, so thanks.\r
  51 \r
  52 I however have discovered one issue that is a pain.\r
  53 \r
  54 I use a bugtracker a lot which has workflows that mean that\r
  55 you don't always get teh initial messages from a bug.\r
  56 \r
  57 To put it in more common terms, imagine this:\r
  58 \r
  59   * Alice sends a mail to a large group of your friends, but\r
  60     not you.\r
  61   * Each of these friends replies, and puts you in Cc for the\r
  62     reply.\r
  63 \r
  64 This will mean that you get several messages that all have\r
  65 References and In-Reply-To set to ids that aren't known to\r
  66 notmuch.\r
  67 \r
  68 This means that it doesn't thread them, and so they aren't\r
  69 grouped in the UI. This becomes painful when you are dealing\r
  70 with several bugs like this. It's almost like being back in\r
  71 the days of a message oriented client, and we know that's\r
  72 not the way to do it.\r
  73 \r
  74 Therefore I'd like to fix this. The obvious way is to\r
  75 introduce documents in to the db for each id we see, and\r
  76 threading should then naturally work better.\r
  77 \r
  78 The only issue I see with doing this is with mail delays.\r
  79 Once we do this we will sometimes receive a message that\r
  80 already has a dummy document. What happens currently with\r
  81 message-id collisions?\r
  82 \r
  83 Therefore I would propose this:\r
  84 \r
  85   * When doing a thread resolution and we have ids that\r
  86     we don't know, add a document to the db that is\r
  87     something like\r
  88 \r
  89     {id: <message-id>\r
  90      thread: <synthesised thread-id>\r
  91      dummy: True\r
  92      content: "Messages missing"\r
  93     }\r
  94 \r
  95   * When we get a message-id conflict check for dummy:True\r
  96     and replace the document if it is there.\r
  97 \r
  98 How does this sound?\r
  99 \r
 100 There could be an issue with synthesising too many threads\r
 101 and then ending up having to try and put a message in two\r
 102 threads? I see there is code for merging threads, would that\r
 103 handle this?\r
 104 \r
 105 Thanks,\r
 106 \r
 107 James\r