thread ordering based on references and/or in-reply-to

diff --git a/32/8ac6b42d8055e289b3199a053b5d9024d1607d b/32/8ac6b42d8055e289b3199a053b5d9024d1607d
new file mode 100644 (file)
index 0000000..218793a
--- /dev/null
+++ b/32/8ac6b42d8055e289b3199a053b5d9024d1607d
@@ -0,0 +1,129 @@
+Return-Path: <flo@chaoflow.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 olra.theworths.org (Postfix) with ESMTP id 6A896431FD0\r
+       for <notmuch@notmuchmail.org>; Mon, 31 Oct 2011 16:08:03 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.01\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
+       tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id BTAIatmguZWr for <notmuch@notmuchmail.org>;\r
+       Mon, 31 Oct 2011 16:08:02 -0700 (PDT)\r
+Received: from tesla.chaoflow.net (tesla.chaoflow.net [188.40.54.22])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id E7A5A431FB6\r
+       for <notmuch@notmuchmail.org>; Mon, 31 Oct 2011 16:08:01 -0700 (PDT)\r
+Received: from eve.chaoflow.net (206-15-76-122.static.twtelecom.net\r
+       [206.15.76.122])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       (Authenticated sender: flo@chaoflow.net)\r
+       by tesla.chaoflow.net (Postfix) with ESMTPSA id 0F54011045\r
+       for <notmuch@notmuchmail.org>; Tue,  1 Nov 2011 00:07:59 +0100 (CET)\r
+Received: by eve.chaoflow.net (Postfix, from userid 1000)\r
+       id 4C769240141; Mon, 31 Oct 2011 16:07:56 -0700 (PDT)\r
+From: Florian Friesdorf <flo@chaoflow.net>\r
+To: notmuch@notmuchmail.org\r
+Subject: thread ordering based on references and/or in-reply-to\r
+User-Agent: Notmuch/0.8 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-unknown-linux-gnu)\r
+Date: Mon, 31 Oct 2011 16:07:56 -0700\r
+Message-ID: <87y5w0bvzn.fsf@eve.chaoflow.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-Virus-Scanned: clamav-milter 0.96.5 at tesla\r
+X-Virus-Status: Clean\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://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: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 31 Oct 2011 23:08:03 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+\r
+Hi,\r
+\r
+I'm looking into taking the References header into account for thread\r
+ordering. So far only In-Reply-To is used. My C/C++ is rusty at best, so\r
+I'd need some help to get this done.\r
+\r
+Carl gave a try on irc already to clear things up for me, reading into\r
+it, I have more questions:\r
+\r
+lib/thread.cc/_resolve_thread_relationships adds messages as replies to\r
+a parent.\r
+\r
+Currently, we seem to treat In-Reply-To as empty or single msgid. If I\r
+understand rfc822 it can be a list of msgids and/or phrases. Do/shall we\r
+support that?\r
+\r
+References is a list of msgids, with the last one being the direct\r
+parent. I don't know how multiple direct parents are handled here.\r
+\r
+DJB recommends "... readers look for identifiers in In-Reply-To and\r
+append them to References if they are not already included in\r
+References." [1]\r
+\r
+In that case if there are two msgids in In-Reply-To and there are\r
+appended to the References list, than only the last one will be a parent\r
+and the one that used to be the last is not a parent anymore.\r
+\r
+And Carl recommends to treat references and in-reply-to as two separated\r
+sources of information, first using in-reply-to and then references in\r
+order "to attach to the deepest referenced parent".=20\r
+\r
+I fail to understand that. Am I complicating things?\r
+How do we want to treat the combination of References/In-Reply-To?\r
+\r
+Do we have code that returns the last msgid listed in references?\r
+database.cc/parse_references seems not to care about order, just\r
+existence - or is GHashTable ordered.\r
+\r
+[1] http://cr.yp.to/immhf/thread.html\r
+\r
+\r
+florian\r
+=2D-=20\r
+Florian Friesdorf <flo@chaoflow.net>\r
+  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083\r
+Jabber/XMPP: flo@chaoflow.net\r
+IRC: chaoflow on freenode,ircnet,blafasel,OFTC\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v2.0.18 (GNU/Linux)\r
+\r
+iQIcBAEBAgAGBQJOrypMAAoJEDj4maMMRfCDS2gP/0mESMAP5Qg9/44e/cVoMkq4\r
+L34h43q0px3m8EW81GgOEHusPo3liI9qYXQHjU/vchBmEdKunWpiZcb+a9iT1dFQ\r
+aQlDSh2PP715WLWEqijqb0O4L0H7zMC5w1WWtTCoIKenUpZG3zulJvjnn1g6pDOt\r
+epaWNU59gXMrKhvuuwVHPHrDg1zM1Utxeei25R+viRWFUy2qfTe2lBkLLFqYr3Xb\r
+mrySuWS7zjQJYmoNFVN/qijaGwuPVDpeLaJ+RBPD/fXts2kOXryQUAOkvPuTNOV6\r
+emUkg8HgMjdURTmu88eih7KKa0G+Nz+aCbXhPGFgCcxpcrdN5uyZNnKwgy/Az6to\r
+SbVChfc3L5+wOzexmODYyXMlDqXh6SjnLHqoiEU+WDeSuorfcJ9CqV0/6k6QyBbU\r
+oyy3XGGadKvRJlIH21pIH7jNmpUPDjrZNUjVsuGmPBIJNS4IxWoY63ymfGBtiZaj\r
+30O40rwBiRnIPDNTO0mgOsQjCwCHQ1rEvdeBMvpV4DTqul0pMaZxDY3ssV8UFLJ/\r
+XmuJjLarKsx9h72QRJdhvquEAEMPiNtAo7ukjKLhcW6XIZwqTP20KRFlK9Zy1WPC\r
+BH2wHNIt5/u5m5eUD9Bgn4wKLmSkhKCF3Yfk+x9UREZ0nymcstZbbOmwuM+1tHWg\r
+3SWnYSiCxp9AdYs4D+c+\r
+=r+bO\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r