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