From e330aa683ffc77fdae2127d39f57f17cada9cb21 Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Mon, 26 Nov 2012 19:19:30 +0200 Subject: [PATCH] Re: [PATCH 0/6] API for iterating over all messages in a thread --- 71/ab11a5705543ac16643bb051a8906674ada9c1 | 120 ++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 71/ab11a5705543ac16643bb051a8906674ada9c1 diff --git a/71/ab11a5705543ac16643bb051a8906674ada9c1 b/71/ab11a5705543ac16643bb051a8906674ada9c1 new file mode 100644 index 000000000..14cb28ff2 --- /dev/null +++ b/71/ab11a5705543ac16643bb051a8906674ada9c1 @@ -0,0 +1,120 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id C9873431FAF + for ; Mon, 26 Nov 2012 09:19:34 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id hh+mDI91KjE8 for ; + Mon, 26 Nov 2012 09:19:34 -0800 (PST) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id B4E48431FAE + for ; Mon, 26 Nov 2012 09:19:33 -0800 (PST) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id 4D6421000E5; + Mon, 26 Nov 2012 19:19:30 +0200 (EET) +From: Tomi Ollila +To: Austin Clements , + Mark Walters +Subject: Re: [PATCH 0/6] API for iterating over all messages in a thread +In-Reply-To: <20121125212059.GN4562@mit.edu> +References: <1353819427-13182-1-git-send-email-amdragon@mit.edu> + <87ehjhkb3a.fsf@qmul.ac.uk> <20121125212059.GN4562@mit.edu> +User-Agent: Notmuch/0.14+84~g8a199bf (http://notmuchmail.org) Emacs/24.2.1 + (x86_64-unknown-linux-gnu) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 26 Nov 2012 17:19:34 -0000 + +On Sun, Nov 25 2012, Austin Clements wrote: + +> Quoth Mark Walters on Nov 25 at 2:31 pm: +>> +>> Hi +>> +>> This series looks good to me (I have not reviewed the two bindings +>> patches). Patch 2 looks like it makes things much easier to follow than +>> the current code (if I understood the current pointer stuff it +>> constructs the top-level list by doing pointer stuff to remove all +>> messages which are replies from the complete message list). Indeed, the +>> diff is more complicated than the new code! +>> +>> On Sun, 25 Nov 2012, Austin Clements wrote: +>> > This series adds a library API for iterating over all messages in a +>> > thread in sorted order. This is easy for the library to provide and +>> > difficult to obtain from the current API. Plus, if you don't count +>> > the code added to the bindings, this series is actually a net +>> > decrease of 4 lines of code because of simplifications it enables. +>> > +>> > Do we want the API to do more? Currently it's very minimal, but I can +>> > imagine two ways it could be generalized. It could take an argument +>> > to indicate which message list to return, which could be all messages, +>> > matched messages, top-level messages, or maybe even unmatched messages +>> > (possibly all in terms of message flags). It could also take an +>> > argument indicating the desired sort order. Currently, the caller can +>> > use existing message flag APIs to distinguish matched and unmatched +>> > messages and there's a separate function for the top-level messages. +>> > However, if the API could do all of these things, it would subsume +>> > various other API functions, such as notmuch_thread_get_*_date. +>> +>> I don't know if this is the right API. For the matched message etc I +>> think using the existing message flag APIs is simple enough. I am not +>> sure about sort orders though: that looks like it would be much easier +>> for the caller to have the correct sort by I am not sure what users +>> would need it. +> +> For sort order, I would be inclined to simply construct the reverse +> list the first time a caller asks for it. Theoretically the caller +> could do this just as easily as the library, except that we don't +> expose the list routines. +> +> If I do add sort order, I would also want to add some control over +> which list is returned, since it would be asymmetric to be able to +> request all messages in either order, but top-level messages only in +> oldest-first. I think this would be pretty simple, and would give us +> a reasonably general-purpose and extensible API. (It would also solve +> the naming conundrum I mentioned below in my original email.) + +The code looks good to me. + +I'm interested to see the extensible interface for returning desired +list in desired sort order :) + +Tomi + +> +>> Best wishes +>> +>> Mark +>> +>> +>> > +>> > Also, is this the right name for the new API? In particular, if we do +>> > later want to add a function that returns, say, the list of matched +>> > messages, we'll have a convention collision with +>> > notmuch_thread_get_matched_messages, which returns only a count. -- 2.26.2