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