1 Return-Path: <amdragon@gmail.com>
\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 198B0431FD0
\r
6 for <notmuch@notmuchmail.org>; Wed, 2 Nov 2011 07:37:08 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
\r
12 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,
\r
13 RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id eqkFKfNGhPJ5 for <notmuch@notmuchmail.org>;
\r
17 Wed, 2 Nov 2011 07:37:06 -0700 (PDT)
\r
18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com
\r
19 [209.85.216.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 229C1431FB6
\r
22 for <notmuch@notmuchmail.org>; Wed, 2 Nov 2011 07:37:06 -0700 (PDT)
\r
23 Received: by qadc1 with SMTP id c1so300406qad.26
\r
24 for <notmuch@notmuchmail.org>; Wed, 02 Nov 2011 07:37:05 -0700 (PDT)
\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
\r
26 h=mime-version:sender:in-reply-to:references:date
\r
27 :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
\r
28 bh=O07AviyzbESVt60lrOMmrMNmSRLwrIo4CJRNJd43knc=;
\r
29 b=TAfA/YJ+v6i1Gn6vDfZe+05J3oQ6bgH28GYPJT23+gN1Tb+ltGHUUDvY54IQH8Eo/E
\r
30 8updnqramwlPFaDUtD8ZSdcRRE/lWpFYw77aVs8IX7f3eDriPpCRXaY9rGmvFKKiTFLG
\r
31 vHj4Veknrh+MoLnsAQqlKr+C/4w9+VLBxfKMg=
\r
33 Received: by 10.68.30.198 with SMTP id u6mr5229505pbh.38.1320244625235; Wed,
\r
34 02 Nov 2011 07:37:05 -0700 (PDT)
\r
35 Sender: amdragon@gmail.com
\r
36 Received: by 10.143.166.17 with HTTP; Wed, 2 Nov 2011 07:37:05 -0700 (PDT)
\r
37 In-Reply-To: <87y5w0bvzn.fsf@eve.chaoflow.net>
\r
38 References: <87y5w0bvzn.fsf@eve.chaoflow.net>
\r
39 Date: Wed, 2 Nov 2011 10:37:05 -0400
\r
40 X-Google-Sender-Auth: QLxgE8proJs59VP2C84wplBZW5c
\r
42 <CAH-f9WuCVVtaA-TY9_Y5WXTYF56g_n19-T0Q6xJcCRU1E1COpw@mail.gmail.com>
\r
43 Subject: Re: thread ordering based on references and/or in-reply-to
\r
44 From: Austin Clements <amdragon@mit.edu>
\r
45 To: Florian Friesdorf <flo@chaoflow.net>
\r
46 Content-Type: text/plain; charset=ISO-8859-1
\r
47 Cc: notmuch@notmuchmail.org
\r
48 X-BeenThere: notmuch@notmuchmail.org
\r
49 X-Mailman-Version: 2.1.13
\r
51 List-Id: "Use and development of the notmuch mail system."
\r
52 <notmuch.notmuchmail.org>
\r
53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
54 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
56 List-Post: <mailto:notmuch@notmuchmail.org>
\r
57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
59 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
60 X-List-Received-Date: Wed, 02 Nov 2011 14:37:08 -0000
\r
62 On Mon, Oct 31, 2011 at 7:07 PM, Florian Friesdorf <flo@chaoflow.net> wrote:
\r
66 > I'm looking into taking the References header into account for thread
\r
67 > ordering. So far only In-Reply-To is used. My C/C++ is rusty at best, so
\r
68 > I'd need some help to get this done.
\r
70 > Carl gave a try on irc already to clear things up for me, reading into
\r
71 > it, I have more questions:
\r
73 > lib/thread.cc/_resolve_thread_relationships adds messages as replies to
\r
76 > Currently, we seem to treat In-Reply-To as empty or single msgid. If I
\r
77 > understand rfc822 it can be a list of msgids and/or phrases. Do/shall we
\r
80 > References is a list of msgids, with the last one being the direct
\r
81 > parent. I don't know how multiple direct parents are handled here.
\r
83 > DJB recommends "... readers look for identifiers in In-Reply-To and
\r
84 > append them to References if they are not already included in
\r
87 > In that case if there are two msgids in In-Reply-To and there are
\r
88 > appended to the References list, than only the last one will be a parent
\r
89 > and the one that used to be the last is not a parent anymore.
\r
91 > And Carl recommends to treat references and in-reply-to as two separated
\r
92 > sources of information, first using in-reply-to and then references in
\r
93 > order "to attach to the deepest referenced parent".
\r
95 > I fail to understand that. Am I complicating things?
\r
96 > How do we want to treat the combination of References/In-Reply-To?
\r
98 > Do we have code that returns the last msgid listed in references?
\r
99 > database.cc/parse_references seems not to care about order, just
\r
100 > existence - or is GHashTable ordered.
\r
102 > [1] http://cr.yp.to/immhf/thread.html
\r
107 I know this came up on IRC, but have you looked at jwz's threading
\r
108 algorithm (http://www.jwz.org/doc/threading.html)? Carl mentioned
\r
109 that notmuch already implements it (except for subject matching), but
\r
110 notmuch only implements the subset of it necessary to group messages
\r
111 into threads without structure. Much of the algorithm is devoted to
\r
112 exactly this problem of piecing together the thread structure based on
\r
113 all of the information in both In-Reply-To and References. The
\r
114 algorithm as described combines the issues of grouping and structuring
\r
115 since it's expecting a giant pile of mail as input, but there's no
\r
116 reason these can't be teased apart.
\r
projects / notmuch-archives.git / blob