From: Austin Clements Date: Sun, 25 Nov 2012 21:20:59 +0000 (+1900) Subject: Re: [PATCH 0/6] API for iterating over all messages in a thread X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=30a1ce73e6363e06daa44c6682e641884fba5f60;p=notmuch-archives.git Re: [PATCH 0/6] API for iterating over all messages in a thread --- diff --git a/cb/ba8409bfea0c1e34ddbb3f78f7a9afb54338e3 b/cb/ba8409bfea0c1e34ddbb3f78f7a9afb54338e3 new file mode 100644 index 000000000..d830fc1f9 --- /dev/null +++ b/cb/ba8409bfea0c1e34ddbb3f78f7a9afb54338e3 @@ -0,0 +1,136 @@ +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 0E9E0431FAE + for ; Sun, 25 Nov 2012 13:21:05 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 hu43GlfC+j7Y for ; + Sun, 25 Nov 2012 13:21:04 -0800 (PST) +Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU + [18.9.25.13]) + by olra.theworths.org (Postfix) with ESMTP id 35323431FAF + for ; Sun, 25 Nov 2012 13:21:04 -0800 (PST) +X-AuditID: 1209190d-b7f906d0000008de-63-50b28bbe7902 +Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) + by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP + id 6B.68.02270.EBB82B05; Sun, 25 Nov 2012 16:21:03 -0500 (EST) +Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) + by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id qAPLL2KF012406; + Sun, 25 Nov 2012 16:21:02 -0500 +Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) + (authenticated bits=0) + (User authenticated as amdragon@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qAPLL05v001016 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); + Sun, 25 Nov 2012 16:21:01 -0500 (EST) +Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) + (envelope-from ) + id 1TcjdL-0004HO-Sj; Sun, 25 Nov 2012 16:20:59 -0500 +Date: Sun, 25 Nov 2012 16:20:59 -0500 +From: Austin Clements +To: Mark Walters +Subject: Re: [PATCH 0/6] API for iterating over all messages in a thread +Message-ID: <20121125212059.GN4562@mit.edu> +References: <1353819427-13182-1-git-send-email-amdragon@mit.edu> + <87ehjhkb3a.fsf@qmul.ac.uk> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <87ehjhkb3a.fsf@qmul.ac.uk> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Brightmail-Tracker: + H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1t3fvSnA4PM+RovVc3ksrt+cyezA + 5LFz1l12j2erbjEHMEVx2aSk5mSWpRbp2yVwZWxf84G54KFYxfstdxgbGL8KdjFyckgImEj8 + fDaDFcIWk7hwbz1bFyMXh5DAPkaJN8962CGcDYwS/xesZIRwLjJJfJn0D8pZwiix9MQHFpB+ + FgFVicc7HjOB2GwCGhLb9i9nBLFFBHQkbh9awA5iMwtIS3z73QxWIyzgIfHg908wm1dAW2Jp + 92+wGiGBOIk1X9tZIOKCEidnPmGB6NWSuPHvJVA9B9ic5f84QMKcQKvabkwFWyUqoCIx5eQ2 + tgmMQrOQdM9C0j0LoXsBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2M4LCW + 5N3B+O6g0iFGAQ5GJR7eG4kbA4RYE8uKK3MPMUpyMCmJ8ja3bgoQ4kvKT6nMSCzOiC8qzUkt + PsQowcGsJMI7kQkox5uSWFmVWpQPk5LmYFES572SctNfSCA9sSQ1OzW1ILUIJivDwaEkwWvf + BdQoWJSanlqRlplTgpBm4uAEGc4DNHxHJ8jw4oLE3OLMdIj8KUZFKXFeNZBmAZBERmkeXC8s + 7bxiFAd6RZiXEaSKB5iy4LpfAQ1mAhqcfH0jyOCSRISUVANj8H5rc/0I+ULHtkWbtOwO2C5i + Zt+hvsLoEotC4FXrz38+TFFuq3m+9uc+1Zwn/6MlNscFuhov3/zx8vaCw0q7f0dMiD06YcWa + 7NM2d5+J/Y9e7O3wdWqbyVktwzM12e2z2zIk9mp9cjrNaX6NMWmetpln2J5zByuYnurbe5oa + 3jbojHOSN7ZUYinOSDTUYi4qTgQA4EabchYDAAA= +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: Sun, 25 Nov 2012 21:21:05 -0000 + +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.) + +> 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.