1 Return-Path: <amdragon@mit.edu>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id BB3A0431FAF
\r
6 for <notmuch@notmuchmail.org>; Mon, 6 Aug 2012 09:47:14 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id 9Ml6I0dPifku for <notmuch@notmuchmail.org>;
\r
16 Mon, 6 Aug 2012 09:47:12 -0700 (PDT)
\r
17 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU
\r
19 by olra.theworths.org (Postfix) with ESMTP id C4E72431FAE
\r
20 for <notmuch@notmuchmail.org>; Mon, 6 Aug 2012 09:47:12 -0700 (PDT)
\r
21 X-AuditID: 1209190f-b7f306d0000008b4-f7-501ff5109266
\r
22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])
\r
23 by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP
\r
24 id B5.37.02228.015FF105; Mon, 6 Aug 2012 12:47:12 -0400 (EDT)
\r
25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
\r
26 by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q76GlBka016635;
\r
27 Mon, 6 Aug 2012 12:47:12 -0400
\r
28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])
\r
29 (authenticated bits=0)
\r
30 (User authenticated as amdragon@ATHENA.MIT.EDU)
\r
31 by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q76GlAQo018537
\r
32 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);
\r
33 Mon, 6 Aug 2012 12:47:11 -0400 (EDT)
\r
34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)
\r
35 (envelope-from <amdragon@mit.edu>)
\r
36 id 1SyQSU-00035Y-CK; Mon, 06 Aug 2012 12:47:10 -0400
\r
37 Date: Mon, 6 Aug 2012 12:47:10 -0400
\r
38 From: Austin Clements <amdragon@MIT.EDU>
\r
39 To: Peter Wang <novalazy@gmail.com>
\r
40 Subject: Re: [PATCH 1/4] show: indicate length of omitted body content (json)
\r
41 Message-ID: <20120806164710.GK22601@mit.edu>
\r
42 References: <1344151345-25411-1-git-send-email-novalazy@gmail.com>
\r
44 Content-Type: text/plain; charset=us-ascii
\r
45 Content-Disposition: inline
\r
46 In-Reply-To: <1344151345-25411-1-git-send-email-novalazy@gmail.com>
\r
47 User-Agent: Mutt/1.5.21 (2010-09-15)
\r
48 X-Brightmail-Tracker:
\r
49 H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT1xX4Kh9g0LlY3OL6zZnMFs9b9zI5
\r
50 MHnsnHWX3ePZqlvMAUxRXDYpqTmZZalF+nYJXBnLju5gLDgkUrFxxzbWBsYmgS5GTg4JAROJ
\r
51 vYvXsEDYYhIX7q1nA7GFBPYxSrx9odTFyAVkr2eU6FtwiBXCOcEk8fjnJKiqJYwSC1blgNgs
\r
52 AioSlxdPYQSx2QQ0JLbtXw5miwgoS/z59QysnllAWuLb72amLkYODmEBX4nLl8tAwrwCOhLN
\r
53 X04wg4SFBJwkJj+1gwgLSpyc+YQFolNL4sa/l2CdIFOW/+MACXMKOEvM3NQPViIKdMCUk9vY
\r
54 JjAKzULSPQtJ9yyE7gWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0TfRyM0v0UlNKNzGCAppT
\r
55 kn8H47eDSocYBTgYlXh4nXrkA4RYE8uKK3MPMUpyMCmJ8sa+AwrxJeWnVGYkFmfEF5XmpBYf
\r
56 YpTgYFYS4a1ZCJTjTUmsrEotyodJSXOwKInzXk256S8kkJ5YkpqdmlqQWgSTleHgUJLgVf4C
\r
57 1ChYlJqeWpGWmVOCkGbi4AQZzgM0/NdnkOHFBYm5xZnpEPlTjIpS4rxiIM0CIImM0jy4XljC
\r
58 ecUoDvSKMEQVDzBZwXW/AhrMBDTYW14OZHBJIkJKCphkfjUar+A+k5nIP1FG5yPTLUn/grdy
\r
59 C/YqnfVJudTx4WLJ2T2neybIc2m+czhaWcT3RGBy1rpD/k0rlj94Hvxtuib3mRfrfYslNq9K
\r
60 WX6rbCLz1qVbeLxcBSQlPlVvS23pKZyaZ798jrHVfG8Ro9VzW67w/eziWPP9re0dvuN3Juw/
\r
61 ebGj4GCJEktxRqKhFnNRcSIAWwXwSxMDAAA=
\r
62 Cc: notmuch@notmuchmail.org
\r
63 X-BeenThere: notmuch@notmuchmail.org
\r
64 X-Mailman-Version: 2.1.13
\r
66 List-Id: "Use and development of the notmuch mail system."
\r
67 <notmuch.notmuchmail.org>
\r
68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
69 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
71 List-Post: <mailto:notmuch@notmuchmail.org>
\r
72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
74 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
75 X-List-Received-Date: Mon, 06 Aug 2012 16:47:14 -0000
\r
77 What's the overall goal of adding this? Are you planning to add size
\r
78 information to one of the frontends?
\r
80 Quoth Peter Wang on Aug 05 at 5:22 pm:
\r
81 > If a leaf part's body content is omitted, return the content length in
\r
82 > --format=json output. This information may be used by the consumer,
\r
83 > e.g. to decide whether to download a large attachment over a slow link.
\r
85 > devel/schemata | 5 ++++-
\r
86 > notmuch-show.c | 8 ++++++++
\r
87 > 2 files changed, 12 insertions(+), 1 deletions(-)
\r
89 > diff --git a/devel/schemata b/devel/schemata
\r
90 > index 9cb25f5..3df2764 100644
\r
91 > --- a/devel/schemata
\r
92 > +++ b/devel/schemata
\r
93 > @@ -69,7 +69,10 @@ part = {
\r
94 > # A leaf part's body content is optional, but may be included if
\r
95 > # it can be correctly encoded as a string. Consumers should use
\r
96 > # this in preference to fetching the part content separately.
\r
97 > - content?: string
\r
98 > + content?: string,
\r
99 > + # If a leaf part's body content is not included, the content-length
\r
100 > + # may be included instead.
\r
102 You mentioned elsewhere that the content-length returned is an
\r
103 estimate. If that's the case, this comment should say as much. Is it
\r
104 actually the case, though? g_mime_part_get_content_object is
\r
105 remarkably poorly documented for such an important function, but based
\r
106 on format_part_raw, it seems like the content-length your code returns
\r
107 will be exactly the number of bytes returned by the raw format for a
\r
110 > + content-length?: int
\r
113 > # The headers of a message or part (format_headers_json with reply = FALSE)
\r
114 > diff --git a/notmuch-show.c b/notmuch-show.c
\r
115 > index 3556293..5c54257 100644
\r
116 > --- a/notmuch-show.c
\r
117 > +++ b/notmuch-show.c
\r
118 > @@ -664,6 +664,14 @@ format_part_json (const void *ctx, sprinter_t *sp, mime_node_t *node,
\r
119 > sp->map_key (sp, "content");
\r
120 > sp->string_len (sp, (char *) part_content->data, part_content->len);
\r
121 > g_object_unref (stream_memory);
\r
123 > + GMimeDataWrapper *wrapper = g_mime_part_get_content_object (GMIME_PART (node->part));
\r
124 > + GMimeStream *stream = g_mime_data_wrapper_get_stream (wrapper);
\r
125 > + ssize_t length = g_mime_stream_length (stream);
\r
126 > + if (length >= 0) {
\r
127 > + sp->map_key (sp, "content-length");
\r
128 > + sp->integer (sp, length);
\r
131 Do wrapper or stream need to be g_object_unref'd?
\r
133 Any idea what the performance overhead of this is? I'm just curious.
\r
134 It might be approximately nothing, since GMime's parser is eager.
\r
137 > } else if (GMIME_IS_MULTIPART (node->part)) {
\r
138 > sp->map_key (sp, "content");
\r