Re: [PATCH 1/4] show: indicate length of omitted body content (json)
authorPeter Wang <novalazy@gmail.com>
Tue, 7 Aug 2012 13:24:14 +0000 (23:24 +1000)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:48:55 +0000 (09:48 -0800)
50/d6fd6ad562b5c9f859662ffbf892b018b4fa8e [new file with mode: 0644]

diff --git a/50/d6fd6ad562b5c9f859662ffbf892b018b4fa8e b/50/d6fd6ad562b5c9f859662ffbf892b018b4fa8e
new file mode 100644 (file)
index 0000000..d49c31c
--- /dev/null
@@ -0,0 +1,133 @@
+Return-Path: <novalazy@gmail.com>\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 58448431FC4\r
+       for <notmuch@notmuchmail.org>; Tue,  7 Aug 2012 06:24:24 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.799\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+       FREEMAIL_FROM=0.001, 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 Gc+xM8XWD6gB for <notmuch@notmuchmail.org>;\r
+       Tue,  7 Aug 2012 06:24:23 -0700 (PDT)\r
+Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com\r
+       [209.85.160.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id C4A57431FAF\r
+       for <notmuch@notmuchmail.org>; Tue,  7 Aug 2012 06:24:23 -0700 (PDT)\r
+Received: by pbbro2 with SMTP id ro2so2233663pbb.26\r
+       for <notmuch@notmuchmail.org>; Tue, 07 Aug 2012 06:24:21 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+       h=date:message-id:from:to:cc:subject:in-reply-to:references\r
+       :mime-version:content-type:content-disposition\r
+       :content-transfer-encoding;\r
+       bh=6RK1/JWuFodHaz4oDBU5cOGDjhWx13/euAwGtat7pMY=;\r
+       b=iEMhyNQdcLIgL4yiNkGGjP9BW1IsI+13h0QbixDm7pRe6q9fKsHncYfqUtQeMCAvHm\r
+       7o8v+Ps05YerfbO+aRobC1c3/yYPO1v0aqe85meRgfzrlYRk3U7rpVQTmmxstE6MtygZ\r
+       VqMI2AMpeIRjyXeyxP8yeuNfwY2hAAfv35RmJnyxBrFV7VsdT6YSWQRhCvGZFDfYCJFa\r
+       XfcKAhZ0k98xEFhVQGcT8i1u46fj2067KxBWmswfalen7UVc6VfqKHSc4CH6lETeKu5W\r
+       l/hZ7hFCdruHvhLHNfIweA2rwy7ugkbmLOJ+j8iE6jwE+huW5G1S8gnk4BmyzhUj0nuX\r
+       CVKw==\r
+Received: by 10.68.213.5 with SMTP id no5mr28224148pbc.24.1344345861893;\r
+       Tue, 07 Aug 2012 06:24:21 -0700 (PDT)\r
+Received: from localhost (215.42.233.220.static.exetel.com.au.\r
+       [220.233.42.215])\r
+       by mx.google.com with ESMTPS id jz4sm11191181pbc.17.2012.08.07.06.24.18\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Tue, 07 Aug 2012 06:24:21 -0700 (PDT)\r
+Date: Tue, 7 Aug 2012 23:24:14 +1000\r
+Message-ID: <20120807232414.GA22132@hili.localdomain>\r
+From: Peter Wang <novalazy@gmail.com>\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH 1/4] show: indicate length of omitted body content (json)\r
+In-Reply-To: <20120806164710.GK22601@mit.edu>\r
+References: <1344151345-25411-1-git-send-email-novalazy@gmail.com>\r
+       <20120806164710.GK22601@mit.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: 8bit\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: Tue, 07 Aug 2012 13:24:24 -0000\r
+\r
+On Mon, 6 Aug 2012 12:47:10 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> What's the overall goal of adding this?  Are you planning to add size\r
+> information to one of the frontends?\r
+\r
+Yes, to my frontend.\r
+\r
+>> > diff --git a/devel/schemata b/devel/schemata\r
+> > index 9cb25f5..3df2764 100644\r
+> > --- a/devel/schemata\r
+> > +++ b/devel/schemata\r
+> > @@ -69,7 +69,10 @@ part = {\r
+> >      # A leaf part's body content is optional, but may be included if\r
+> >      # it can be correctly encoded as a string.  Consumers should use\r
+> >      # this in preference to fetching the part content separately.\r
+> > -    content?:       string\r
+> > +    content?:       string,\r
+> > +    # If a leaf part's body content is not included, the content-length\r
+> > +    # may be included instead.\r
+> \r
+> You mentioned elsewhere that the content-length returned is an\r
+> estimate.  If that's the case, this comment should say as much.  Is it\r
+> actually the case, though?  g_mime_part_get_content_object is\r
+> remarkably poorly documented for such an important function, but based\r
+> on format_part_raw, it seems like the content-length your code returns\r
+> will be exactly the number of bytes returned by the raw format for a\r
+> leaf part.\r
+\r
+It's the exact length of the _encoded_ content.  If the transfer\r
+encoding is base64, multiplying by 3/4 will get a close estimate of the\r
+decoded content length.  I assume quoted-printable encoding would only\r
+be used if the content is mostly ASCII, so the encoded length can serve\r
+as the estimated decoded length then.\r
+\r
+> > diff --git a/notmuch-show.c b/notmuch-show.c\r
+> > index 3556293..5c54257 100644\r
+> > --- a/notmuch-show.c\r
+> > +++ b/notmuch-show.c\r
+> > @@ -664,6 +664,14 @@ format_part_json (const void *ctx, sprinter_t *sp, mime_node_t *node,\r
+> >        sp->map_key (sp, "content");\r
+> >        sp->string_len (sp, (char *) part_content->data, part_content->len);\r
+> >        g_object_unref (stream_memory);\r
+> > +  } else {\r
+> > +      GMimeDataWrapper *wrapper = g_mime_part_get_content_object (GMIME_PART (node->part));\r
+> > +      GMimeStream *stream = g_mime_data_wrapper_get_stream (wrapper);\r
+> > +      ssize_t length = g_mime_stream_length (stream);\r
+> > +      if (length >= 0) {\r
+> > +          sp->map_key (sp, "content-length");\r
+> > +          sp->integer (sp, length);\r
+> > +      }\r
+> \r
+> Do wrapper or stream need to be g_object_unref'd?\r
+\r
+No.\r
+\r
+> Any idea what the performance overhead of this is?  I'm just curious.\r
+> It might be approximately nothing, since GMime's parser is eager.\r
+\r
+The start and end bounds of the stream are already known so there's\r
+approximately nothing for g_mime_stream_length to do.  The other\r
+functions simply return field values.\r
+\r
+I'll drop the changes for text output.\r
+\r
+Peter\r