Re: thread ordering based on references and/or in-reply-to
authorAustin Clements <amdragon@mit.edu>
Wed, 2 Nov 2011 14:37:05 +0000 (10:37 +2000)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:39:58 +0000 (09:39 -0800)
63/c88f8439fc600084bbcee5ec24f15de9cb8351 [new file with mode: 0644]

diff --git a/63/c88f8439fc600084bbcee5ec24f15de9cb8351 b/63/c88f8439fc600084bbcee5ec24f15de9cb8351
new file mode 100644 (file)
index 0000000..31edbba
--- /dev/null
@@ -0,0 +1,116 @@
+Return-Path: <amdragon@gmail.com>\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 198B0431FD0\r
+       for <notmuch@notmuchmail.org>; Wed,  2 Nov 2011 07:37:08 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.699\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
+       RCVD_IN_DNSWL_LOW=-0.7] 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 eqkFKfNGhPJ5 for <notmuch@notmuchmail.org>;\r
+       Wed,  2 Nov 2011 07:37:06 -0700 (PDT)\r
+Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com\r
+       [209.85.216.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 229C1431FB6\r
+       for <notmuch@notmuchmail.org>; Wed,  2 Nov 2011 07:37:06 -0700 (PDT)\r
+Received: by qadc1 with SMTP id c1so300406qad.26\r
+       for <notmuch@notmuchmail.org>; Wed, 02 Nov 2011 07:37:05 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+       h=mime-version:sender:in-reply-to:references:date\r
+       :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
+       bh=O07AviyzbESVt60lrOMmrMNmSRLwrIo4CJRNJd43knc=;\r
+       b=TAfA/YJ+v6i1Gn6vDfZe+05J3oQ6bgH28GYPJT23+gN1Tb+ltGHUUDvY54IQH8Eo/E\r
+       8updnqramwlPFaDUtD8ZSdcRRE/lWpFYw77aVs8IX7f3eDriPpCRXaY9rGmvFKKiTFLG\r
+       vHj4Veknrh+MoLnsAQqlKr+C/4w9+VLBxfKMg=\r
+MIME-Version: 1.0\r
+Received: by 10.68.30.198 with SMTP id u6mr5229505pbh.38.1320244625235; Wed,\r
+       02 Nov 2011 07:37:05 -0700 (PDT)\r
+Sender: amdragon@gmail.com\r
+Received: by 10.143.166.17 with HTTP; Wed, 2 Nov 2011 07:37:05 -0700 (PDT)\r
+In-Reply-To: <87y5w0bvzn.fsf@eve.chaoflow.net>\r
+References: <87y5w0bvzn.fsf@eve.chaoflow.net>\r
+Date: Wed, 2 Nov 2011 10:37:05 -0400\r
+X-Google-Sender-Auth: QLxgE8proJs59VP2C84wplBZW5c\r
+Message-ID:\r
+ <CAH-f9WuCVVtaA-TY9_Y5WXTYF56g_n19-T0Q6xJcCRU1E1COpw@mail.gmail.com>\r
+Subject: Re: thread ordering based on references and/or in-reply-to\r
+From: Austin Clements <amdragon@mit.edu>\r
+To: Florian Friesdorf <flo@chaoflow.net>\r
+Content-Type: text/plain; charset=ISO-8859-1\r
+Cc: notmuch@notmuchmail.org\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: Wed, 02 Nov 2011 14:37:08 -0000\r
+\r
+On Mon, Oct 31, 2011 at 7:07 PM, Florian Friesdorf <flo@chaoflow.net> wrote:\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".\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
+\r
+I know this came up on IRC, but have you looked at jwz's threading\r
+algorithm (http://www.jwz.org/doc/threading.html)?  Carl mentioned\r
+that notmuch already implements it (except for subject matching), but\r
+notmuch only implements the subset of it necessary to group messages\r
+into threads without structure.  Much of the algorithm is devoted to\r
+exactly this problem of piecing together the thread structure based on\r
+all of the information in both In-Reply-To and References.  The\r
+algorithm as described combines the issues of grouping and structuring\r
+since it's expecting a giant pile of mail as input, but there's no\r
+reason these can't be teased apart.\r