Re: [PATCH v3 2/5] reply: Add a JSON reply format.

diff --git a/22/6a61bfba2120132928f1ab8ef246fbb32463d5 b/22/6a61bfba2120132928f1ab8ef246fbb32463d5
new file mode 100644 (file)
index 0000000..ddd6fd8
--- /dev/null
+++ b/22/6a61bfba2120132928f1ab8ef246fbb32463d5
@@ -0,0 +1,107 @@
+Return-Path: <awg@xvx.ca>\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 D7436431FAF\r
+       for <notmuch@notmuchmail.org>; Sun,  5 Feb 2012 11:42:14 -0800 (PST)\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 4BN5S62w0cYg for <notmuch@notmuchmail.org>;\r
+       Sun,  5 Feb 2012 11:42:14 -0800 (PST)\r
+Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com\r
+       [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 231C5431FAE\r
+       for <notmuch@notmuchmail.org>; Sun,  5 Feb 2012 11:42:14 -0800 (PST)\r
+Received: by bke11 with SMTP id 11so4921842bke.26\r
+       for <notmuch@notmuchmail.org>; Sun, 05 Feb 2012 11:42:12 -0800 (PST)\r
+MIME-Version: 1.0\r
+Received: by 10.204.152.88 with SMTP id f24mr6988544bkw.31.1328470932637; Sun,\r
+       05 Feb 2012 11:42:12 -0800 (PST)\r
+Sender: awg@xvx.ca\r
+Received: by 10.204.104.13 with HTTP; Sun, 5 Feb 2012 11:42:12 -0800 (PST)\r
+X-Originating-IP: [96.52.216.56]\r
+In-Reply-To: <87mx8xpki3.fsf@qmul.ac.uk>\r
+References: <1326995217-27423-1-git-send-email-awg+notmuch@xvx.ca>\r
+       <1326995217-27423-3-git-send-email-awg+notmuch@xvx.ca>\r
+       <87mx8xpki3.fsf@qmul.ac.uk>\r
+Date: Sun, 5 Feb 2012 12:42:12 -0700\r
+X-Google-Sender-Auth: HZo5Bc1rP1ZkylxqA2wJAh7fj9w\r
+Message-ID:\r
+ <CAMoJFUusrzG9GcAwrbK0iNDaUOCVsc=e-i-n0tEcSOSF4XBn0Q@mail.gmail.com>\r
+Subject: Re: [PATCH v3 2/5] reply: Add a JSON reply format.\r
+From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>\r
+To: Mark Walters <markwalters1009@gmail.com>\r
+Content-Type: text/plain; charset=ISO-8859-1\r
+Content-Transfer-Encoding: quoted-printable\r
+Cc: 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: Sun, 05 Feb 2012 19:42:15 -0000\r
+\r
+Thanks for the review. The style nits are things I missed in my\r
+previous cleanup, so thanks for pointing them out. I should probably\r
+run uncrustify and see if it complains about anything else.\r
+\r
+The other points are definitely up for discussion, and some are areas\r
+where I was unsure to start with. Discussion inline:\r
+\r
+On Sun, Feb 5, 2012 at 04:50, Mark Walters <markwalters1009@gmail.com> wrot=\r
+e:\r
+>> + =A0 =A0/* We only care about inline text parts for reply purposes */\r
+>> + =A0 =A0if (reply_check_part_type (part, "text", "*", GMIME_DISPOSITION=\r
+_INLINE)) {\r
+>\r
+> This seems to be different from the logic in the text output: I think\r
+> that inlines all text/* regardless of disposition. I think the JSON\r
+> output should include at least as much as the text output as it is easy\r
+> for the caller to discard parts.\r
+\r
+Indeed, the text output includes all text/* parts except for\r
+text/html, regardless of disposition. My thought was that it doesn't\r
+really make sense to quote an attachment, or at least it's not the\r
+behavior I would expect. But, perhaps it makes more sense to include\r
+all the text parts, with their dispositions, and let the MUA decide\r
+what it wants to quote. If anyone has thoughts on this I'm happy to\r
+hear them.\r
+\r
+> Does wrapper need to a free/unref somewhere?\r
+\r
+The text format doesn't free or unref wrapper, so I followed its\r
+example. But, I'm not a gmime expert, and I agree intuitively that it\r
+should be freed somehow. Can anyone enlighten me?\r
+\r
+> If replying to multiple messages (such as a whole thread) you get\r
+> multiple sets of "new headers". I think that probably is not what is\r
+> wanted but its still better than the weird things the text version\r
+> does. Might be worth putting a comment. [What I think should happen is\r
+> that a union of all the headers from all these is taken throwing away\r
+> duplicate addresses but that is obviously not part of this patch set]\r
+\r
+I've never been sure about what the intended behavior is when replying\r
+to multiple messages in the CLI. My thought was that it should create\r
+a reply to each message, so an MUA could iterate over them allowing\r
+you to compose replies to multiple messages. But, I've never wanted or\r
+used such a feature, so I'm agnostic on whether it's right. The emacs\r
+MUA (at least with my patch) ignores all but the first reply object in\r
+the array, my assumption being that reply only operates on multiple\r
+messages by accident.\r
+\r
+Does anyone use reply with multiple messages? If so, what semantics do\r
+you expect?\r