Date: Mon, 6 Aug 2012 12:47:10 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Peter Wang <novalazy@gmail.com>
Subject: Re: [PATCH 1/4] show: indicate length of omitted body content (json)
Message-ID: <20120806164710.GK22601@mit.edu>
References: <1344151345-25411-1-git-send-email-novalazy@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1344151345-25411-1-git-send-email-novalazy@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

What's the overall goal of adding this?  Are you planning to add size
information to one of the frontends?

Quoth Peter Wang on Aug 05 at  5:22 pm:
> If a leaf part's body content is omitted, return the content length in
> --format=json output.  This information may be used by the consumer,
> e.g. to decide whether to download a large attachment over a slow link.
> ---
>  devel/schemata |    5 ++++-
>  notmuch-show.c |    8 ++++++++
>  2 files changed, 12 insertions(+), 1 deletions(-)
> 
> 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.

> +    content-length?: int
>  }
>  
>  # The headers of a message or part (format_headers_json with reply = FALSE)
> 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?

Any idea what the performance overhead of this is?  I'm just curious.
It might be approximately nothing, since GMime's parser is eager.

>  	}
>      } else if (GMIME_IS_MULTIPART (node->part)) {
>  	sp->map_key (sp, "content");