1 Return-Path: <tomi.ollila@iki.fi>
\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 C9873431FAF
\r
6 for <notmuch@notmuchmail.org>; Mon, 26 Nov 2012 09:19:34 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\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 hh+mDI91KjE8 for <notmuch@notmuchmail.org>;
\r
16 Mon, 26 Nov 2012 09:19:34 -0800 (PST)
\r
17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])
\r
18 by olra.theworths.org (Postfix) with ESMTP id B4E48431FAE
\r
19 for <notmuch@notmuchmail.org>; Mon, 26 Nov 2012 09:19:33 -0800 (PST)
\r
20 Received: from guru.guru-group.fi (localhost [IPv6:::1])
\r
21 by guru.guru-group.fi (Postfix) with ESMTP id 4D6421000E5;
\r
22 Mon, 26 Nov 2012 19:19:30 +0200 (EET)
\r
23 From: Tomi Ollila <tomi.ollila@iki.fi>
\r
24 To: Austin Clements <amdragon@MIT.EDU>,
\r
25 Mark Walters <markwalters1009@gmail.com>
\r
26 Subject: Re: [PATCH 0/6] API for iterating over all messages in a thread
\r
27 In-Reply-To: <20121125212059.GN4562@mit.edu>
\r
28 References: <1353819427-13182-1-git-send-email-amdragon@mit.edu>
\r
29 <87ehjhkb3a.fsf@qmul.ac.uk> <20121125212059.GN4562@mit.edu>
\r
30 User-Agent: Notmuch/0.14+84~g8a199bf (http://notmuchmail.org) Emacs/24.2.1
\r
31 (x86_64-unknown-linux-gnu)
\r
32 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL
\r
33 $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F
\r
34 !)g;OY^,BjTbr)Np:%c_o'jj,Z
\r
35 Date: Mon, 26 Nov 2012 19:19:30 +0200
\r
36 Message-ID: <m2624sffj1.fsf@guru.guru-group.fi>
\r
38 Content-Type: text/plain
\r
39 Cc: notmuch@notmuchmail.org
\r
40 X-BeenThere: notmuch@notmuchmail.org
\r
41 X-Mailman-Version: 2.1.13
\r
43 List-Id: "Use and development of the notmuch mail system."
\r
44 <notmuch.notmuchmail.org>
\r
45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
46 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
48 List-Post: <mailto:notmuch@notmuchmail.org>
\r
49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
52 X-List-Received-Date: Mon, 26 Nov 2012 17:19:34 -0000
\r
54 On Sun, Nov 25 2012, Austin Clements <amdragon@MIT.EDU> wrote:
\r
56 > Quoth Mark Walters on Nov 25 at 2:31 pm:
\r
60 >> This series looks good to me (I have not reviewed the two bindings
\r
61 >> patches). Patch 2 looks like it makes things much easier to follow than
\r
62 >> the current code (if I understood the current pointer stuff it
\r
63 >> constructs the top-level list by doing pointer stuff to remove all
\r
64 >> messages which are replies from the complete message list). Indeed, the
\r
65 >> diff is more complicated than the new code!
\r
67 >> On Sun, 25 Nov 2012, Austin Clements <amdragon@MIT.EDU> wrote:
\r
68 >> > This series adds a library API for iterating over all messages in a
\r
69 >> > thread in sorted order. This is easy for the library to provide and
\r
70 >> > difficult to obtain from the current API. Plus, if you don't count
\r
71 >> > the code added to the bindings, this series is actually a net
\r
72 >> > decrease of 4 lines of code because of simplifications it enables.
\r
74 >> > Do we want the API to do more? Currently it's very minimal, but I can
\r
75 >> > imagine two ways it could be generalized. It could take an argument
\r
76 >> > to indicate which message list to return, which could be all messages,
\r
77 >> > matched messages, top-level messages, or maybe even unmatched messages
\r
78 >> > (possibly all in terms of message flags). It could also take an
\r
79 >> > argument indicating the desired sort order. Currently, the caller can
\r
80 >> > use existing message flag APIs to distinguish matched and unmatched
\r
81 >> > messages and there's a separate function for the top-level messages.
\r
82 >> > However, if the API could do all of these things, it would subsume
\r
83 >> > various other API functions, such as notmuch_thread_get_*_date.
\r
85 >> I don't know if this is the right API. For the matched message etc I
\r
86 >> think using the existing message flag APIs is simple enough. I am not
\r
87 >> sure about sort orders though: that looks like it would be much easier
\r
88 >> for the caller to have the correct sort by I am not sure what users
\r
91 > For sort order, I would be inclined to simply construct the reverse
\r
92 > list the first time a caller asks for it. Theoretically the caller
\r
93 > could do this just as easily as the library, except that we don't
\r
94 > expose the list routines.
\r
96 > If I do add sort order, I would also want to add some control over
\r
97 > which list is returned, since it would be asymmetric to be able to
\r
98 > request all messages in either order, but top-level messages only in
\r
99 > oldest-first. I think this would be pretty simple, and would give us
\r
100 > a reasonably general-purpose and extensible API. (It would also solve
\r
101 > the naming conundrum I mentioned below in my original email.)
\r
103 The code looks good to me.
\r
105 I'm interested to see the extensible interface for returning desired
\r
106 list in desired sort order :)
\r
117 >> > Also, is this the right name for the new API? In particular, if we do
\r
118 >> > later want to add a function that returns, say, the list of matched
\r
119 >> > messages, we'll have a convention collision with
\r
120 >> > notmuch_thread_get_matched_messages, which returns only a count.
\r
projects / notmuch-archives.git / blob