32/8ac6b42d8055e289b3199a053b5d9024d1607d

   1 Return-Path: <flo@chaoflow.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 6A896431FD0\r
   6         for <notmuch@notmuchmail.org>; Mon, 31 Oct 2011 16:08:03 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.01\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
  12         tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id BTAIatmguZWr for <notmuch@notmuchmail.org>;\r
  16         Mon, 31 Oct 2011 16:08:02 -0700 (PDT)\r
  17 Received: from tesla.chaoflow.net (tesla.chaoflow.net [188.40.54.22])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id E7A5A431FB6\r
  21         for <notmuch@notmuchmail.org>; Mon, 31 Oct 2011 16:08:01 -0700 (PDT)\r
  22 Received: from eve.chaoflow.net (206-15-76-122.static.twtelecom.net\r
  23         [206.15.76.122])\r
  24         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  25         (No client certificate requested)\r
  26         (Authenticated sender: flo@chaoflow.net)\r
  27         by tesla.chaoflow.net (Postfix) with ESMTPSA id 0F54011045\r
  28         for <notmuch@notmuchmail.org>; Tue,  1 Nov 2011 00:07:59 +0100 (CET)\r
  29 Received: by eve.chaoflow.net (Postfix, from userid 1000)\r
  30         id 4C769240141; Mon, 31 Oct 2011 16:07:56 -0700 (PDT)\r
  31 From: Florian Friesdorf <flo@chaoflow.net>\r
  32 To: notmuch@notmuchmail.org\r
  33 Subject: thread ordering based on references and/or in-reply-to\r
  34 User-Agent: Notmuch/0.8 (http://notmuchmail.org) Emacs/23.3.1\r
  35         (x86_64-unknown-linux-gnu)\r
  36 Date: Mon, 31 Oct 2011 16:07:56 -0700\r
  37 Message-ID: <87y5w0bvzn.fsf@eve.chaoflow.net>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: multipart/signed; boundary="=-=-=";\r
  40         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  41 X-Virus-Scanned: clamav-milter 0.96.5 at tesla\r
  42 X-Virus-Status: Clean\r
  43 X-BeenThere: notmuch@notmuchmail.org\r
  44 X-Mailman-Version: 2.1.13\r
  45 Precedence: list\r
  46 List-Id: "Use and development of the notmuch mail system."\r
  47         <notmuch.notmuchmail.org>\r
  48 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  50 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  51 List-Post: <mailto:notmuch@notmuchmail.org>\r
  52 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  53 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  55 X-List-Received-Date: Mon, 31 Oct 2011 23:08:03 -0000\r
  56 \r
  57 --=-=-=\r
  58 Content-Transfer-Encoding: quoted-printable\r
  59 \r
  60 \r
  61 Hi,\r
  62 \r
  63 I'm looking into taking the References header into account for thread\r
  64 ordering. So far only In-Reply-To is used. My C/C++ is rusty at best, so\r
  65 I'd need some help to get this done.\r
  66 \r
  67 Carl gave a try on irc already to clear things up for me, reading into\r
  68 it, I have more questions:\r
  69 \r
  70 lib/thread.cc/_resolve_thread_relationships adds messages as replies to\r
  71 a parent.\r
  72 \r
  73 Currently, we seem to treat In-Reply-To as empty or single msgid. If I\r
  74 understand rfc822 it can be a list of msgids and/or phrases. Do/shall we\r
  75 support that?\r
  76 \r
  77 References is a list of msgids, with the last one being the direct\r
  78 parent. I don't know how multiple direct parents are handled here.\r
  79 \r
  80 DJB recommends "... readers look for identifiers in In-Reply-To and\r
  81 append them to References if they are not already included in\r
  82 References." [1]\r
  83 \r
  84 In that case if there are two msgids in In-Reply-To and there are\r
  85 appended to the References list, than only the last one will be a parent\r
  86 and the one that used to be the last is not a parent anymore.\r
  87 \r
  88 And Carl recommends to treat references and in-reply-to as two separated\r
  89 sources of information, first using in-reply-to and then references in\r
  90 order "to attach to the deepest referenced parent".=20\r
  91 \r
  92 I fail to understand that. Am I complicating things?\r
  93 How do we want to treat the combination of References/In-Reply-To?\r
  94 \r
  95 Do we have code that returns the last msgid listed in references?\r
  96 database.cc/parse_references seems not to care about order, just\r
  97 existence - or is GHashTable ordered.\r
  98 \r
  99 [1] http://cr.yp.to/immhf/thread.html\r
 100 \r
 101 \r
 102 florian\r
 103 =2D-=20\r
 104 Florian Friesdorf <flo@chaoflow.net>\r
 105   GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083\r
 106 Jabber/XMPP: flo@chaoflow.net\r
 107 IRC: chaoflow on freenode,ircnet,blafasel,OFTC\r
 108 \r
 109 --=-=-=\r
 110 Content-Type: application/pgp-signature\r
 111 \r
 112 -----BEGIN PGP SIGNATURE-----\r
 113 Version: GnuPG v2.0.18 (GNU/Linux)\r
 114 \r
 115 iQIcBAEBAgAGBQJOrypMAAoJEDj4maMMRfCDS2gP/0mESMAP5Qg9/44e/cVoMkq4\r
 116 L34h43q0px3m8EW81GgOEHusPo3liI9qYXQHjU/vchBmEdKunWpiZcb+a9iT1dFQ\r
 117 aQlDSh2PP715WLWEqijqb0O4L0H7zMC5w1WWtTCoIKenUpZG3zulJvjnn1g6pDOt\r
 118 epaWNU59gXMrKhvuuwVHPHrDg1zM1Utxeei25R+viRWFUy2qfTe2lBkLLFqYr3Xb\r
 119 mrySuWS7zjQJYmoNFVN/qijaGwuPVDpeLaJ+RBPD/fXts2kOXryQUAOkvPuTNOV6\r
 120 emUkg8HgMjdURTmu88eih7KKa0G+Nz+aCbXhPGFgCcxpcrdN5uyZNnKwgy/Az6to\r
 121 SbVChfc3L5+wOzexmODYyXMlDqXh6SjnLHqoiEU+WDeSuorfcJ9CqV0/6k6QyBbU\r
 122 oyy3XGGadKvRJlIH21pIH7jNmpUPDjrZNUjVsuGmPBIJNS4IxWoY63ymfGBtiZaj\r
 123 30O40rwBiRnIPDNTO0mgOsQjCwCHQ1rEvdeBMvpV4DTqul0pMaZxDY3ssV8UFLJ/\r
 124 XmuJjLarKsx9h72QRJdhvquEAEMPiNtAo7ukjKLhcW6XIZwqTP20KRFlK9Zy1WPC\r
 125 BH2wHNIt5/u5m5eUD9Bgn4wKLmSkhKCF3Yfk+x9UREZ0nymcstZbbOmwuM+1tHWg\r
 126 3SWnYSiCxp9AdYs4D+c+\r
 127 =r+bO\r
 128 -----END PGP SIGNATURE-----\r
 129 --=-=-=--\r