d3/2f1fb8bddf97e143af6613514538a0c7157bcd

   1 Return-Path: <m.walters@qmul.ac.uk>\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 7EADB431FAF\r
   6         for <notmuch@notmuchmail.org>; Sun, 25 Nov 2012 06:31:53 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.098\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] 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 AE3q1EUdB+U4 for <notmuch@notmuchmail.org>;\r
  17         Sun, 25 Nov 2012 06:31:53 -0800 (PST)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id BAC1A431FAE\r
  22         for <notmuch@notmuchmail.org>; Sun, 25 Nov 2012 06:31:52 -0800 (PST)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1TcdFN-0005IS-OZ; Sun, 25 Nov 2012 14:31:50 +0000\r
  27 Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)\r
  28         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
  29         (envelope-from <m.walters@qmul.ac.uk>)\r
  30         id 1TcdFN-000037-Eq; Sun, 25 Nov 2012 14:31:49 +0000\r
  31 From: Mark Walters <markwalters1009@gmail.com>\r
  32 To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org\r
  33 Subject: Re: [PATCH 0/6] API for iterating over all messages in a thread\r
  34 In-Reply-To: <1353819427-13182-1-git-send-email-amdragon@mit.edu>\r
  35 References: <1353819427-13182-1-git-send-email-amdragon@mit.edu>\r
  36 User-Agent: Notmuch/0.14+81~g9730584 (http://notmuchmail.org) Emacs/23.4.1\r
  37         (x86_64-pc-linux-gnu)\r
  38 Date: Sun, 25 Nov 2012 14:31:53 +0000\r
  39 Message-ID: <87ehjhkb3a.fsf@qmul.ac.uk>\r
  40 MIME-Version: 1.0\r
  41 Content-Type: text/plain; charset=us-ascii\r
  42 X-Sender-Host-Address: 93.97.24.31\r
  43 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  44 X-QM-Body-MD5: 16a83e3a07d2e2f1f8cd05b77f6d967f (of first 20000 bytes)\r
  45 X-SpamAssassin-Score: -1.8\r
  46 X-SpamAssassin-SpamBar: -\r
  47 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  48         determine if it is\r
  49         spam. We require at least 5.0 points to mark a message as spam.\r
  50         This message scored -1.8 points.\r
  51         Summary of the scoring: \r
  52         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
  53         *      medium trust\r
  54         *      [138.37.6.40 listed in list.dnswl.org]\r
  55         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  56         provider *      (markwalters1009[at]gmail.com)\r
  57         *  0.5 AWL AWL: From: address is in the auto white-list\r
  58 X-QM-Scan-Virus: ClamAV says the message is clean\r
  59 X-BeenThere: notmuch@notmuchmail.org\r
  60 X-Mailman-Version: 2.1.13\r
  61 Precedence: list\r
  62 List-Id: "Use and development of the notmuch mail system."\r
  63         <notmuch.notmuchmail.org>\r
  64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  67 List-Post: <mailto:notmuch@notmuchmail.org>\r
  68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  71 X-List-Received-Date: Sun, 25 Nov 2012 14:31:53 -0000\r
  72 \r
  73 \r
  74 Hi\r
  75 \r
  76 This series looks good to me (I have not reviewed the two bindings\r
  77 patches). Patch 2 looks like it makes things much easier to follow than\r
  78 the current code (if I understood the current pointer stuff it\r
  79 constructs the top-level list by doing pointer stuff to remove all\r
  80 messages which are replies from the complete message list). Indeed, the\r
  81 diff is more complicated than the new code!\r
  82 \r
  83 On Sun, 25 Nov 2012, Austin Clements <amdragon@MIT.EDU> wrote:\r
  84 > This series adds a library API for iterating over all messages in a\r
  85 > thread in sorted order.  This is easy for the library to provide and\r
  86 > difficult to obtain from the current API.  Plus, if you don't count\r
  87 > the code added to the bindings, this series is actually a net\r
  88 > decrease of 4 lines of code because of simplifications it enables.\r
  89 >\r
  90 > Do we want the API to do more?  Currently it's very minimal, but I can\r
  91 > imagine two ways it could be generalized.  It could take an argument\r
  92 > to indicate which message list to return, which could be all messages,\r
  93 > matched messages, top-level messages, or maybe even unmatched messages\r
  94 > (possibly all in terms of message flags).  It could also take an\r
  95 > argument indicating the desired sort order.  Currently, the caller can\r
  96 > use existing message flag APIs to distinguish matched and unmatched\r
  97 > messages and there's a separate function for the top-level messages.\r
  98 > However, if the API could do all of these things, it would subsume\r
  99 > various other API functions, such as notmuch_thread_get_*_date.\r
 100 \r
 101 I don't know if this is the right API. For the matched message etc I\r
 102 think using the existing message flag APIs is simple enough. I am not\r
 103 sure about sort orders though: that looks like it would be much easier\r
 104 for the caller to have the correct sort by I am not sure what users\r
 105 would need it.\r
 106 \r
 107 Best wishes\r
 108 \r
 109 Mark\r
 110 \r
 111 \r
 112 \r
 113 \r
 114 >\r
 115 > Also, is this the right name for the new API?  In particular, if we do\r
 116 > later want to add a function that returns, say, the list of matched\r
 117 > messages, we'll have a convention collision with\r
 118 > notmuch_thread_get_matched_messages, which returns only a count.\r