--- /dev/null
+Return-Path: <amdragon@mit.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id D6996431FAF\r
+ for <notmuch@notmuchmail.org>; Sat, 8 Sep 2012 10:23:41 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id gNRBx3D4a-9n for <notmuch@notmuchmail.org>;\r
+ Sat, 8 Sep 2012 10:23:41 -0700 (PDT)\r
+Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU\r
+ [18.9.25.13])\r
+ by olra.theworths.org (Postfix) with ESMTP id 2B8EC431FAE\r
+ for <notmuch@notmuchmail.org>; Sat, 8 Sep 2012 10:23:41 -0700 (PDT)\r
+X-AuditID: 1209190d-b7f9a6d0000009ad-dc-504b7f1cc535\r
+Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
+ by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id 6D.D6.02477.C1F7B405; Sat, 8 Sep 2012 13:23:40 -0400 (EDT)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+ by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q88HNd8Y014311; \r
+ Sat, 8 Sep 2012 13:23:40 -0400\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q88HNcDK026273\r
+ (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+ Sat, 8 Sep 2012 13:23:39 -0400 (EDT)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1TAOkr-00061L-UN; Sat, 08 Sep 2012 13:23:38 -0400\r
+Date: Sat, 8 Sep 2012 13:23:37 -0400\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>\r
+Subject: Re: [PATCH 00/11] add recipients to search output\r
+Message-ID: <20120908172337.GB11179@mit.edu>\r
+References: <1345427570-26518-1-git-send-email-jrollins@finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <1345427570-26518-1-git-send-email-jrollins@finestructure.net>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6noitT7x1g0NKjbrFnn5fF9ZszmR2Y\r
+ PO6e5vJ4tuoWcwBTFJdNSmpOZllqkb5dAlfG6XnvmQr+KlTcu7mWpYFxq1QXIyeHhICJxL/J\r
+ K1kgbDGJC/fWs4HYQgL7GCU6/8h2MXIB2esZJW7s3sUOkTjBJPHkKgtEYgmjxImuc0AJDg4W\r
+ ARWJTZ1JIDVsAhoS2/YvZwSxRQTMJHq+/AGzmQW0JLZu/ABmCwtYSWz49pQJxOYV0JE4dHQ5\r
+ K8R8L4mF7T3MEHFBiZMzn7DA9N7495IJZBWzgLTE8n8cIGFOAW+JCRs3gt0sCnTBlJPb2CYw\r
+ Cs1C0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxgsKZU5J3\r
+ B+O7g0qHGAU4GJV4eDfIeQUIsSaWFVfmHmKU5GBSEuXdXeMdIMSXlJ9SmZFYnBFfVJqTWnyI\r
+ UYKDWUmE93o6UI43JbGyKrUoHyYlzcGiJM57JeWmv5BAemJJanZqakFqEUxWhoNDSYK3vA6o\r
+ UbAoNT21Ii0zpwQhzcTBCTKcB2h4AUgNb3FBYm5xZjpE/hSjopQ4rzfIRQIgiYzSPLheWLp5\r
+ xSgO9Iowry1IOw8wVcF1vwIazAQ0WOSZB8jgkkSElFQDo63L/oRvkpVrWhKO/nVf2J8osN1I\r
+ 78SPkvfcbQ4fYl8YVlrND2ItVs6u5/S4E/W24NGLG+vsjy7VjGA4saCqi/3KAiXG/y8Y0/aE\r
+ fhK7V1AuICy5g+HNh92vCwVstHd9Tuwv7z746W2ywMUXCd2G1zaLGH5ecZXbLmzOVn+P9/lO\r
+ H4OUSjLWKrEUZyQaajEXFScCAInG7i8SAwAA\r
+Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 08 Sep 2012 17:23:42 -0000\r
+\r
+Quoth Jameson Graef Rollins on Aug 19 at 6:52 pm:\r
+> This series is an attempt to add thread recipients to the search\r
+> output.\r
+> \r
+> My personal overall goal of this series is to support the handling of\r
+> drafts in the emacs ui. For drafts we want to see recipients, instead\r
+> of authors, in the search output. I can imagine other uses for this\r
+> series as well, though.\r
+> \r
+> The first four patches generalize the author list handling in thread\r
+> objects to handle any address list. These patches could be applied\r
+> regardless of if the rest of the series is accepted.\r
+> \r
+> After that we modify the thread constructor such that it can hold\r
+> thread recipients as well. Since there is overhead in retrieving\r
+> thread recipients from the message files (recipients are not stored in\r
+> the database) this is handled with a switch.\r
+> \r
+> Further patches add the new switch to the search CLI that adds thread\r
+> recipients to the structured output formats. I didn't modify the text\r
+> output format, since there is no way to extend it. I can imagine\r
+> tweaking the text output such that the author field is instead\r
+> replaced by the recipients (as is done for the emacs UI at the end of\r
+> the series), but that's not done here.\r
+\r
+I've gotten up through patch 8. Overall I really like this series and\r
+the abstractions you're introducing. However, I don't think you\r
+should replicate the way the authors list is handled in the CLI. The\r
+authors list is a kludge inherited from the text format, which had to\r
+invent a syntax for lists, that somehow got baked into the library.\r
+JSON, on the other hand, is very good at lists, and should use them\r
+for the recipients (I would love if it used them for the authors list,\r
+but that'll require an incompatible change, so I'd like to implement\r
+my/some JSON versioning scheme first). After all, "The string is a\r
+stark data structure and everywhere it is passed there is much\r
+duplication of process. It is a perfect vehicle for hiding\r
+information."\r
+\r
+I think treating recipients as a first-class list would lead to a much\r
+cleaner and more general API; it would hard-code less in the library,\r
+though it would put more responsibility on the CLI. What I'm\r
+imagining is just a single new public API function:\r
+notmuch_thread_get_messages, which returns a notmuch_messages_t of the\r
+thread's messages, in the original query's sort order. It's\r
+remarkable that we *don't* have this API already. In this case, it\r
+would give the library user (the CLI) the ability to easily construct\r
+the recipients list however it wants. JSON list or text string? No\r
+problem. Just to or to/cc/bcc? No problem. Separating matched and\r
+unmatched or merging them together? No problem. Also, since this\r
+would naturally construct the recipients list only when needed, we\r
+wouldn't have to worry about telling the library whether or not to pay\r
+the performance cost, and we could trivially add the headers we end up\r
+using to the database later and get an automatic speed boost.\r
+\r
+Relative to your current code, this would require either duplicating a\r
+bit of the matched/unmatched hash table code in the CLI (not perfect,\r
+but you wouldn't need the stringifying function, and there isn't much\r
+other code to that) or moving the thread_addresses abstraction into\r
+util. _thread_cleanup_author would probably also want to move into\r
+util (which is also completely reasonable since it's a pure leaf\r
+function that depends on nothing).\r
+\r
+> In the emacs UI, I add a new toggle function that will toggle display\r
+> of thread authors or recipients in the 'authors' field of the search\r
+> output. It's unfortunate that this ambiguity in that field name\r
+> remains, but I didn't know how to change that cleanly. I'm working on\r
+> some tests for the new emacs functionality that I'll include in the\r
+> inevitable v2 of this series.\r
+> \r
+> The last patch is mostly just a tickle to suggest adding the\r
+> recipients to the database. It would make the --include-recipient\r
+> searches much faster of course, but it might be overhead in the\r
+> database that folks aren't interested in.\r
+> \r
+> As always, feedback, review, and comments are much appreciated.\r
+> \r
+> jamie.\r
projects / notmuch-archives.git / commitdiff