[PATCH 1/4] show: indicate length of omitted body content (json)
Peter Wang writes: > 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. It looks like this patch series was thoroughly reviewed and then obsoleted by the series in id:"1344428872-12374-1-git-send-email-novalazy at gmail.com". I'm therefore marking it notmuch::obsolete, and will review the other patch set. Ethan
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
Peter Wang noval...@gmail.com writes: 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. It looks like this patch series was thoroughly reviewed and then obsoleted by the series in id:1344428872-12374-1-git-send-email-noval...@gmail.com. I'm therefore marking it notmuch::obsolete, and will review the other patch set. Ethan ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] show: indicate length of omitted body content (json)
On Wed, 08 Aug 2012 00:01:06 +0100, Mark Walters wrote: > > I have two minor queries: do you think omitted text/html parts should > also have the length given? Or even should it always be sent? But I am > happy with it as is. It could be added. I wouldn't have much use for it myself. text/html parts should usually be small enough that it doesn't matter, and I never retrieve them when there is a text/plain alternative. Peter
[PATCH 1/4] show: indicate length of omitted body content (json)
I like this (and agree with Austin and you that text and json can
diverge). I just hacked something together which uses this and makes the
emacs front-end display the content-length on part buttons and as
someone who uses notmuch over ssh that is nice.
I have two minor queries: do you think omitted text/html parts should
also have the length given? Or even should it always be sent? But I am
happy with it as is.
I haven't checked the test patch (or the text ones as they are being
dropped).
Best wishes
Mark
On Sun, 05 Aug 2012, Peter Wang wrote:
> 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.
> +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);
> + }
> }
> } else if (GMIME_IS_MULTIPART (node->part)) {
> sp->map_key (sp, "content");
> --
> 1.7.4.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] show: indicate length of omitted body content (json)
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
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
On Wed, 08 Aug 2012 00:01:06 +0100, Mark Walters markwalters1...@gmail.com wrote: I have two minor queries: do you think omitted text/html parts should also have the length given? Or even should it always be sent? But I am happy with it as is. It could be added. I wouldn't have much use for it myself. text/html parts should usually be small enough that it doesn't matter, and I never retrieve them when there is a text/plain alternative. Peter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] show: indicate length of omitted body content (json)
Quoting Peter Wang :
> 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.
Ah, I see. format_part_raw misled me; apparently the
g_mime_data_wrapper_write_to_stream is key there, since *that* decodes
the transfer encoding of the data wrapper's underlying, raw stream.
In that case, the comment could either mention that this is the length
of the transfer encoded content or it could say it's an approximation
of the decoded length. The advantage of only claiming the latter is
that it would leave open the possibility of, say, multiplying by .75
for base64 transfer encoding to get a better decoded estimate (your
assumption about quoted-printable sounds completely reasonable).
Alternatively, we could add the transfer encoding in the future and
let the caller do such approximations.
>> > 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.
Sounds good.
> I'll drop the changes for text output.
>
> Peter
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
On Mon, 6 Aug 2012 12:47:10 -0400, Austin Clements amdra...@mit.edu 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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
Quoting Peter Wang noval...@gmail.com:
On Mon, 6 Aug 2012 12:47:10 -0400, Austin Clements amdra...@mit.edu 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.
Ah, I see. format_part_raw misled me; apparently the
g_mime_data_wrapper_write_to_stream is key there, since *that* decodes
the transfer encoding of the data wrapper's underlying, raw stream.
In that case, the comment could either mention that this is the length
of the transfer encoded content or it could say it's an approximation
of the decoded length. The advantage of only claiming the latter is
that it would leave open the possibility of, say, multiplying by .75
for base64 transfer encoding to get a better decoded estimate (your
assumption about quoted-printable sounds completely reasonable).
Alternatively, we could add the transfer encoding in the future and
let the caller do such approximations.
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.
Sounds good.
I'll drop the changes for text output.
Peter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
I like this (and agree with Austin and you that text and json can
diverge). I just hacked something together which uses this and makes the
emacs front-end display the content-length on part buttons and as
someone who uses notmuch over ssh that is nice.
I have two minor queries: do you think omitted text/html parts should
also have the length given? Or even should it always be sent? But I am
happy with it as is.
I haven't checked the test patch (or the text ones as they are being
dropped).
Best wishes
Mark
On Sun, 05 Aug 2012, Peter Wang noval...@gmail.com wrote:
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.
+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);
+ }
}
} else if (GMIME_IS_MULTIPART (node-part)) {
sp-map_key (sp, content);
--
1.7.4.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
On Sun, 05 Aug 2012 14:37:02 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Sun, Aug 05 2012, Peter Wang noval...@gmail.com wrote:
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.
+content-length?: int
Hey, Peter. Something somewhere, and probably at least here in the
schemata, should mention what the uids are (b? kB? KiB? YiB?)
I thought content-length was a MIME header, but it's not.
Anyway, it's the length of the encoded content in bytes. GMime
doesn't provide an easy way to return the length of the decoded content.
I actually only need an _estimate_ of the decoded size to present to the
user. Strictly speaking, that requires knowledge of the transfer encoding.
Previously I planned on guessing it from the content-type, but I think
it's better to return the transfer encoding as well (if any).
Alternatively, notmuch could put in more effort to return the exact
length of the decoded content. But it's a waste of time if no consumers
will use it.
Peter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] show: indicate length of omitted body content (json)
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.
+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);
+ }
}
} else if (GMIME_IS_MULTIPART (node->part)) {
sp->map_key (sp, "content");
--
1.7.4.4
[PATCH 1/4] show: indicate length of omitted body content (json)
On Sun, Aug 05 2012, Peter Wang wrote:
> 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.
> +content-length?: int
Hey, Peter. Something somewhere, and probably at least here in the
schemata, should mention what the uids are (b? kB? KiB? YiB?)
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
[PATCH 1/4] show: indicate length of omitted body content (json)
On Sun, Aug 05 2012, Peter Wang wrote:
> 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.
> ---
Code looks good to me and tests pass. So I am not against pushing...
Tomi
> 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.
> +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);
> + }
> }
> } else if (GMIME_IS_MULTIPART (node->part)) {
> sp->map_key (sp, "content");
> --
> 1.7.4.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] show: indicate length of omitted body content (json)
On Sun, Aug 05 2012, Peter Wang noval...@gmail.com wrote:
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.
+content-length?: int
Hey, Peter. Something somewhere, and probably at least here in the
schemata, should mention what the uids are (b? kB? KiB? YiB?)
jamie.
pgpiAJg2w2AkP.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
