[PATCH 1/4] show: indicate length of omitted body content (json)
Austin Clements
amdragon at MIT.EDU
Mon Aug 6 09:47:10 PDT 2012
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");
More information about the notmuch
mailing list