85/d0c3fab36eebcdbac7122140682263c17adba3

   1 Return-Path: <amdragon@mit.edu>\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 D6996431FAF\r
   6         for <notmuch@notmuchmail.org>; Sat,  8 Sep 2012 10:23:41 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 gNRBx3D4a-9n for <notmuch@notmuchmail.org>;\r
  16         Sat,  8 Sep 2012 10:23:41 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU\r
  18         [18.9.25.13])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 2B8EC431FAE\r
  20         for <notmuch@notmuchmail.org>; Sat,  8 Sep 2012 10:23:41 -0700 (PDT)\r
  21 X-AuditID: 1209190d-b7f9a6d0000009ad-dc-504b7f1cc535\r
  22 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  23         by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 6D.D6.02477.C1F7B405; Sat,  8 Sep 2012 13:23:40 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q88HNd8Y014311; \r
  27         Sat, 8 Sep 2012 13:23:40 -0400\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q88HNcDK026273\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sat, 8 Sep 2012 13:23:39 -0400 (EDT)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1TAOkr-00061L-UN; Sat, 08 Sep 2012 13:23:38 -0400\r
  37 Date: Sat, 8 Sep 2012 13:23:37 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Jameson Graef Rollins <jrollins@finestructure.net>\r
  40 Subject: Re: [PATCH 00/11] add recipients to search output\r
  41 Message-ID: <20120908172337.GB11179@mit.edu>\r
  42 References: <1345427570-26518-1-git-send-email-jrollins@finestructure.net>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: text/plain; charset=us-ascii\r
  45 Content-Disposition: inline\r
  46 In-Reply-To: <1345427570-26518-1-git-send-email-jrollins@finestructure.net>\r
  47 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  48 X-Brightmail-Tracker:\r
  49  H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6noitT7x1g0NKjbrFnn5fF9ZszmR2Y\r
  50         PO6e5vJ4tuoWcwBTFJdNSmpOZllqkb5dAlfG6XnvmQr+KlTcu7mWpYFxq1QXIyeHhICJxL/J\r
  51         K1kgbDGJC/fWs4HYQgL7GCU6/8h2MXIB2esZJW7s3sUOkTjBJPHkKgtEYgmjxImuc0AJDg4W\r
  52         ARWJTZ1JIDVsAhoS2/YvZwSxRQTMJHq+/AGzmQW0JLZu/ABmCwtYSWz49pQJxOYV0JE4dHQ5\r
  53         K8R8L4mF7T3MEHFBiZMzn7DA9N7495IJZBWzgLTE8n8cIGFOAW+JCRs3gt0sCnTBlJPb2CYw\r
  54         Cs1C0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxgsKZU5J3\r
  55         B+O7g0qHGAU4GJV4eDfIeQUIsSaWFVfmHmKU5GBSEuXdXeMdIMSXlJ9SmZFYnBFfVJqTWnyI\r
  56         UYKDWUmE93o6UI43JbGyKrUoHyYlzcGiJM57JeWmv5BAemJJanZqakFqEUxWhoNDSYK3vA6o\r
  57         UbAoNT21Ii0zpwQhzcTBCTKcB2h4AUgNb3FBYm5xZjpE/hSjopQ4rzfIRQIgiYzSPLheWLp5\r
  58         xSgO9Iowry1IOw8wVcF1vwIazAQ0WOSZB8jgkkSElFQDo63L/oRvkpVrWhKO/nVf2J8osN1I\r
  59         78SPkvfcbQ4fYl8YVlrND2ItVs6u5/S4E/W24NGLG+vsjy7VjGA4saCqi/3KAiXG/y8Y0/aE\r
  60         fhK7V1AuICy5g+HNh92vCwVstHd9Tuwv7z746W2ywMUXCd2G1zaLGH5ecZXbLmzOVn+P9/lO\r
  61         H4OUSjLWKrEUZyQaajEXFScCAInG7i8SAwAA\r
  62 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
  63 X-BeenThere: notmuch@notmuchmail.org\r
  64 X-Mailman-Version: 2.1.13\r
  65 Precedence: list\r
  66 List-Id: "Use and development of the notmuch mail system."\r
  67         <notmuch.notmuchmail.org>\r
  68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  71 List-Post: <mailto:notmuch@notmuchmail.org>\r
  72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  75 X-List-Received-Date: Sat, 08 Sep 2012 17:23:42 -0000\r
  76 \r
  77 Quoth Jameson Graef Rollins on Aug 19 at  6:52 pm:\r
  78 > This series is an attempt to add thread recipients to the search\r
  79 > output.\r
  80 > \r
  81 > My personal overall goal of this series is to support the handling of\r
  82 > drafts in the emacs ui.  For drafts we want to see recipients, instead\r
  83 > of authors, in the search output.  I can imagine other uses for this\r
  84 > series as well, though.\r
  85 > \r
  86 > The first four patches generalize the author list handling in thread\r
  87 > objects to handle any address list.  These patches could be applied\r
  88 > regardless of if the rest of the series is accepted.\r
  89 > \r
  90 > After that we modify the thread constructor such that it can hold\r
  91 > thread recipients as well.  Since there is overhead in retrieving\r
  92 > thread recipients from the message files (recipients are not stored in\r
  93 > the database) this is handled with a switch.\r
  94 > \r
  95 > Further patches add the new switch to the search CLI that adds thread\r
  96 > recipients to the structured output formats.  I didn't modify the text\r
  97 > output format, since there is no way to extend it.  I can imagine\r
  98 > tweaking the text output such that the author field is instead\r
  99 > replaced by the recipients (as is done for the emacs UI at the end of\r
 100 > the series), but that's not done here.\r
 101 \r
 102 I've gotten up through patch 8.  Overall I really like this series and\r
 103 the abstractions you're introducing.  However, I don't think you\r
 104 should replicate the way the authors list is handled in the CLI.  The\r
 105 authors list is a kludge inherited from the text format, which had to\r
 106 invent a syntax for lists, that somehow got baked into the library.\r
 107 JSON, on the other hand, is very good at lists, and should use them\r
 108 for the recipients (I would love if it used them for the authors list,\r
 109 but that'll require an incompatible change, so I'd like to implement\r
 110 my/some JSON versioning scheme first).  After all, "The string is a\r
 111 stark data structure and everywhere it is passed there is much\r
 112 duplication of process. It is a perfect vehicle for hiding\r
 113 information."\r
 114 \r
 115 I think treating recipients as a first-class list would lead to a much\r
 116 cleaner and more general API; it would hard-code less in the library,\r
 117 though it would put more responsibility on the CLI.  What I'm\r
 118 imagining is just a single new public API function:\r
 119 notmuch_thread_get_messages, which returns a notmuch_messages_t of the\r
 120 thread's messages, in the original query's sort order.  It's\r
 121 remarkable that we *don't* have this API already.  In this case, it\r
 122 would give the library user (the CLI) the ability to easily construct\r
 123 the recipients list however it wants.  JSON list or text string?  No\r
 124 problem.  Just to or to/cc/bcc?  No problem.  Separating matched and\r
 125 unmatched or merging them together?  No problem.  Also, since this\r
 126 would naturally construct the recipients list only when needed, we\r
 127 wouldn't have to worry about telling the library whether or not to pay\r
 128 the performance cost, and we could trivially add the headers we end up\r
 129 using to the database later and get an automatic speed boost.\r
 130 \r
 131 Relative to your current code, this would require either duplicating a\r
 132 bit of the matched/unmatched hash table code in the CLI (not perfect,\r
 133 but you wouldn't need the stringifying function, and there isn't much\r
 134 other code to that) or moving the thread_addresses abstraction into\r
 135 util.  _thread_cleanup_author would probably also want to move into\r
 136 util (which is also completely reasonable since it's a pure leaf\r
 137 function that depends on nothing).\r
 138 \r
 139 > In the emacs UI, I add a new toggle function that will toggle display\r
 140 > of thread authors or recipients in the 'authors' field of the search\r
 141 > output.  It's unfortunate that this ambiguity in that field name\r
 142 > remains, but I didn't know how to change that cleanly.  I'm working on\r
 143 > some tests for the new emacs functionality that I'll include in the\r
 144 > inevitable v2 of this series.\r
 145 > \r
 146 > The last patch is mostly just a tickle to suggest adding the\r
 147 > recipients to the database.  It would make the --include-recipient\r
 148 > searches much faster of course, but it might be overhead in the\r
 149 > database that folks aren't interested in.\r
 150 > \r
 151 > As always, feedback, review, and comments are much appreciated.\r
 152 > \r
 153 > jamie.\r