Re: alot: can't read sent emails, after encryption
[notmuch-archives.git] / 43 / 078a3cd975a7674c1a3e388d0d7c5eda72cbe6
1 Return-Path: <novalazy@gmail.com>\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 45797431FAF\r
6         for <notmuch@notmuchmail.org>; Mon,  6 Aug 2012 07:37:07 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.799\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id ZOwomuIRqIVh for <notmuch@notmuchmail.org>;\r
17         Mon,  6 Aug 2012 07:37:06 -0700 (PDT)\r
18 Received: from mail-gh0-f181.google.com (mail-gh0-f181.google.com\r
19         [209.85.160.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id A85DF431FAE\r
22         for <notmuch@notmuchmail.org>; Mon,  6 Aug 2012 07:37:06 -0700 (PDT)\r
23 Received: by ghz3 with SMTP id 3so863543ghz.26\r
24         for <notmuch@notmuchmail.org>; Mon, 06 Aug 2012 07:37:05 -0700 (PDT)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
26         h=date:message-id:from:to:cc:subject:in-reply-to:references\r
27         :mime-version:content-type:content-disposition\r
28         :content-transfer-encoding;\r
29         bh=DAiVgAPM6rAgZdt7HNzY6+DMrjf9zMo/5UKQulnLJ/E=;\r
30         b=IO1mLgznH7WT/4SBwTTtzPKXu97EY35mH17Qbm9mjqfsDUxkTzrCV4q2CCpI8QdarK\r
31         8ewzNmRvG60Ycqmg1iSYkFws/L9c379yEQ2luEqJo6IiS/v6ClEjDkJ0ehSeIlzkY/jm\r
32         NeiVMoC+V5JNnJqkeFGkUu6prn3QI2l+UjkyHrl7mkHccLyU5e3238t42ek3PRx5Sp7X\r
33         DSbK4bcHzJ1rLXMsv6/0AlxS6l4pooaIYg7jSsPVM5Xgqz/B7OyRBKYlchzwmPLVVPkL\r
34         kvn4NsLNYqdaiDMVjA2zHJgG901Qe9GboxjqFrCQSqwPYEeCMWQq+EE1Bsl9G1aaYR1l\r
35         BetA==\r
36 Received: by 10.68.203.98 with SMTP id kp2mr19386113pbc.132.1344263825501;\r
37         Mon, 06 Aug 2012 07:37:05 -0700 (PDT)\r
38 Received: from localhost (215.42.233.220.static.exetel.com.au.\r
39         [220.233.42.215])\r
40         by mx.google.com with ESMTPS id wn1sm1741522pbc.57.2012.08.06.07.37.02\r
41         (version=TLSv1/SSLv3 cipher=OTHER);\r
42         Mon, 06 Aug 2012 07:37:04 -0700 (PDT)\r
43 Date: Tue, 7 Aug 2012 00:36:59 +1000\r
44 Message-ID: <20120807003659.GA22470@hili.localdomain>\r
45 From: Peter Wang <novalazy@gmail.com>\r
46 To: Jameson Graef Rollins <jrollins@finestructure.net>\r
47 Subject: Re: [PATCH 1/4] show: indicate length of omitted body content (json)\r
48 In-Reply-To: <87y5ltuikh.fsf@servo.finestructure.net>\r
49 References: <1344151345-25411-1-git-send-email-novalazy@gmail.com>\r
50         <87y5ltuikh.fsf@servo.finestructure.net>\r
51 MIME-Version: 1.0\r
52 Content-Type: text/plain; charset=utf-8\r
53 Content-Disposition: inline\r
54 Content-Transfer-Encoding: 8bit\r
55 Cc: notmuch@notmuchmail.org\r
56 X-BeenThere: notmuch@notmuchmail.org\r
57 X-Mailman-Version: 2.1.13\r
58 Precedence: list\r
59 List-Id: "Use and development of the notmuch mail system."\r
60         <notmuch.notmuchmail.org>\r
61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
62         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
64 List-Post: <mailto:notmuch@notmuchmail.org>\r
65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
67         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
68 X-List-Received-Date: Mon, 06 Aug 2012 14:37:07 -0000\r
69 \r
70 On Sun, 05 Aug 2012 14:37:02 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
71 > On Sun, Aug 05 2012, Peter Wang <novalazy@gmail.com> wrote:\r
72 > > diff --git a/devel/schemata b/devel/schemata\r
73 > > index 9cb25f5..3df2764 100644\r
74 > > --- a/devel/schemata\r
75 > > +++ b/devel/schemata\r
76 > > @@ -69,7 +69,10 @@ part = {\r
77 > >      # A leaf part's body content is optional, but may be included if\r
78 > >      # it can be correctly encoded as a string.  Consumers should use\r
79 > >      # this in preference to fetching the part content separately.\r
80 > > -    content?:       string\r
81 > > +    content?:       string,\r
82 > > +    # If a leaf part's body content is not included, the content-length\r
83 > > +    # may be included instead.\r
84 > > +    content-length?: int\r
85\r
86 > Hey, Peter.  Something somewhere, and probably at least here in the\r
87 > schemata, should mention what the uids are (b? kB? KiB? YiB?)\r
88 \r
89 I thought content-length was a MIME header, but it's not.\r
90 Anyway, it's the length of the encoded content in bytes.  GMime\r
91 doesn't provide an easy way to return the length of the decoded content.\r
92 \r
93 I actually only need an _estimate_ of the decoded size to present to the\r
94 user.  Strictly speaking, that requires knowledge of the transfer encoding.\r
95 Previously I planned on guessing it from the content-type, but I think\r
96 it's better to return the transfer encoding as well (if any).\r
97 \r
98 Alternatively, notmuch could put in more effort to return the exact\r
99 length of the decoded content.  But it's a waste of time if no consumers\r
100 will use it.\r
101 \r
102 Peter\r