--- /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 4A0D0431FC0\r
+ for <notmuch@notmuchmail.org>; Tue, 7 Aug 2012 06:57:35 -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 yjMv52OfeAe8 for <notmuch@notmuchmail.org>;\r
+ Tue, 7 Aug 2012 06:57:34 -0700 (PDT)\r
+Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU\r
+ [18.7.68.34])\r
+ by olra.theworths.org (Postfix) with ESMTP id 50531431FAF\r
+ for <notmuch@notmuchmail.org>; Tue, 7 Aug 2012 06:57:34 -0700 (PDT)\r
+X-AuditID: 12074422-b7f1f6d00000090b-9e-50211ecd0f4b\r
+Received: from mailhub-3.mit.edu ( [18.9.21.44])\r
+ by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id AC.4E.02315.DCE11205; Tue, 7 Aug 2012 09:57:33 -0400 (EDT)\r
+Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104])\r
+ by mailhub-3.mit.edu (8.13.8/8.9.2) with ESMTP id q77DvXll015115;\r
+ Tue, 7 Aug 2012 09:57:33 -0400\r
+Received: from webmail-10.mit.edu (WEBMAIL-10.MIT.EDU [18.9.23.20]) )\r
+ by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id q77E0Nvd003893;\r
+ Tue, 7 Aug 2012 10:00:24 -0400 (EDT)\r
+Received: from webmail-10.mit.edu (webmail-10.mit.edu [127.0.0.1]) by\r
+ webmail-10.mit.edu (8.13.8) with ESMTP\r
+ id q77DvQOn013771; Tue, 7 Aug 2012 09:57:26 -0400\r
+Received: (from nobody@localhost)\r
+ by webmail-10.mit.edu (8.13.8/8.13.8/Submit) id q77DvQu5013770;\r
+ Tue, 7 Aug 2012 09:57:26 -0400\r
+X-Authentication-Warning: webmail-10.mit.edu: nobody set sender to\r
+ amdragon@mit.edu using -f\r
+Received: from 209-6-116-242.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com\r
+ (209-6-116-242.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com [209.6.116.242]) \r
+ (User authenticated as amdragon@ATHENA.MIT.EDU) by webmail.mit.edu\r
+ (Horde MIME library) with HTTP; Tue, 07 Aug 2012 09:57:26 -0400\r
+Message-ID: <20120807095726.o066wknhk4sk804k@webmail.mit.edu>\r
+Date: Tue, 07 Aug 2012 09:57:26 -0400\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Peter Wang <novalazy@gmail.com>\r
+Subject: Re: [PATCH 1/4] show: indicate length of omitted body content (json)\r
+References: <1344151345-25411-1-git-send-email-novalazy@gmail.com>\r
+ <20120806164710.GK22601@mit.edu>\r
+ <20120807232414.GA22132@hili.localdomain>\r
+In-Reply-To: <20120807232414.GA22132@hili.localdomain>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain;\r
+ charset=UTF-8;\r
+ format="flowed"\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: 7bit\r
+User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsUixCmqo3tWTjHAoHOvqcX1mzOZLZ637mVy\r
+ YPLYOesuu8ezVbeYA5iiuGxSUnMyy1KL9O0SuDKedl1nKVgvU3Hv1SXmBsa9Yl2MnBwSAiYS\r
+ j7s7WCBsMYkL99azdTFycQgJ7GSU2DzpG5SzmVHi5NU1THCZzoenGSGcBYwS30/8YgfpFxJo\r
+ YZRYebMUYlaMRNOeY8wQRVOZJBbufwdWxCtgK/Hr0EpWEJtFQFVixbTbTCA2m4CGxLb9yxlB\r
+ bBEBZYk/v56xgdjMAtIS3343g9UIC/hLND1sZYEY2s8o0bfkNdjlnAJmEp/+fGOEWCAocXLm\r
+ ExaIZhuJEz+2Ai3jABu0/B8HRFheYvvbOcwgtqiAucSDvTsYJzCKzULSPQtJ9yyE7llIuhcw\r
+ sqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIiip2F6UdjD8PKh1iFOBgVOLh\r
+ vcClECDEmlhWXJl7iFGSg0lJlLdERDFAiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv4Z1A5bwp\r
+ iZVVqUX5MClpDhYlcd5rKTf9hQTSE0tSs1NTC1KLYLIyHBxKErxiwOQhJFiUmp5akZaZU4KQ\r
+ ZuLgBBnOAzRcFqSGt7ggMbc4Mx0if4pRUUqclxUkIQCSyCjNg+uFJb1XjOJArwjz6oNU8QAT\r
+ Jlz3K6DBTECDveXlQAaXJCKkpBoY9T+Jxi9WyBZRN5K7/8SaySTLIri/eF1HmP2p63mNKmkG\r
+ jhaFr3ksXgS9fr9SJbxq/Z+nNoIGyi8ecHDu2NMy5Z1jLpNlmkhS7IGney4ppXEtnL1qIn/P\r
+ 0arZKacFN9dO2fdaO0j3rVh5DrvVuwwfli619C0e54psG2aqi127cfq82LfKk5JKLMUZiYZa\r
+ zEXFiQD1UuH6VQMAAA==\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:57:35 -0000\r
+\r
+Quoting Peter Wang <novalazy@gmail.com>:\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
+Ah, I see. format_part_raw misled me; apparently the\r
+g_mime_data_wrapper_write_to_stream is key there, since *that* decodes\r
+the transfer encoding of the data wrapper's underlying, raw stream.\r
+\r
+In that case, the comment could either mention that this is the length\r
+of the transfer encoded content or it could say it's an approximation\r
+of the decoded length. The advantage of only claiming the latter is\r
+that it would leave open the possibility of, say, multiplying by .75\r
+for base64 transfer encoding to get a better decoded estimate (your\r
+assumption about quoted-printable sounds completely reasonable).\r
+Alternatively, we could add the transfer encoding in the future and\r
+let the caller do such approximations.\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 \r
+>> *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 \r
+>> (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
+Sounds good.\r
+\r
+> I'll drop the changes for text output.\r
+>\r
+> Peter\r
+\r