91/264092644dafe4ec08f0c42b01980fc8a98a92

   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 4A0D0431FC0\r
   6         for <notmuch@notmuchmail.org>; Tue,  7 Aug 2012 06:57:35 -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.7\r
  10 X-Spam-Level: \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 yjMv52OfeAe8 for <notmuch@notmuchmail.org>;\r
  16         Tue,  7 Aug 2012 06:57:34 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU\r
  18         [18.7.68.34])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 50531431FAF\r
  20         for <notmuch@notmuchmail.org>; Tue,  7 Aug 2012 06:57:34 -0700 (PDT)\r
  21 X-AuditID: 12074422-b7f1f6d00000090b-9e-50211ecd0f4b\r
  22 Received: from mailhub-3.mit.edu ( [18.9.21.44])\r
  23         by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id AC.4E.02315.DCE11205; Tue,  7 Aug 2012 09:57:33 -0400 (EDT)\r
  25 Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104])\r
  26         by mailhub-3.mit.edu (8.13.8/8.9.2) with ESMTP id q77DvXll015115;\r
  27         Tue, 7 Aug 2012 09:57:33 -0400\r
  28 Received: from webmail-10.mit.edu (WEBMAIL-10.MIT.EDU [18.9.23.20]) )\r
  29         by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id q77E0Nvd003893;\r
  30         Tue, 7 Aug 2012 10:00:24 -0400 (EDT)\r
  31 Received: from webmail-10.mit.edu (webmail-10.mit.edu [127.0.0.1]) by\r
  32         webmail-10.mit.edu (8.13.8) with ESMTP\r
  33         id q77DvQOn013771; Tue, 7 Aug 2012 09:57:26 -0400\r
  34 Received: (from nobody@localhost)\r
  35         by webmail-10.mit.edu (8.13.8/8.13.8/Submit) id q77DvQu5013770;\r
  36         Tue, 7 Aug 2012 09:57:26 -0400\r
  37 X-Authentication-Warning: webmail-10.mit.edu: nobody set sender to\r
  38         amdragon@mit.edu using -f\r
  39 Received: from 209-6-116-242.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com\r
  40         (209-6-116-242.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com [209.6.116.242]) \r
  41         (User authenticated as amdragon@ATHENA.MIT.EDU) by webmail.mit.edu\r
  42         (Horde MIME library) with HTTP; Tue, 07 Aug 2012 09:57:26 -0400\r
  43 Message-ID: <20120807095726.o066wknhk4sk804k@webmail.mit.edu>\r
  44 Date: Tue, 07 Aug 2012 09:57:26 -0400\r
  45 From: Austin Clements <amdragon@MIT.EDU>\r
  46 To: Peter Wang <novalazy@gmail.com>\r
  47 Subject: Re: [PATCH 1/4] show: indicate length of omitted body content (json)\r
  48 References: <1344151345-25411-1-git-send-email-novalazy@gmail.com>\r
  49         <20120806164710.GK22601@mit.edu>\r
  50         <20120807232414.GA22132@hili.localdomain>\r
  51 In-Reply-To: <20120807232414.GA22132@hili.localdomain>\r
  52 MIME-Version: 1.0\r
  53 Content-Type: text/plain;\r
  54         charset=UTF-8;\r
  55         format="flowed"\r
  56 Content-Disposition: inline\r
  57 Content-Transfer-Encoding: 7bit\r
  58 User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)\r
  59 X-Brightmail-Tracker:\r
  60  H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsUixCmqo3tWTjHAoHOvqcX1mzOZLZ637mVy\r
  61         YPLYOesuu8ezVbeYA5iiuGxSUnMyy1KL9O0SuDKedl1nKVgvU3Hv1SXmBsa9Yl2MnBwSAiYS\r
  62         j7s7WCBsMYkL99azdTFycQgJ7GSU2DzpG5SzmVHi5NU1THCZzoenGSGcBYwS30/8YgfpFxJo\r
  63         YZRYebMUYlaMRNOeY8wQRVOZJBbufwdWxCtgK/Hr0EpWEJtFQFVixbTbTCA2m4CGxLb9yxlB\r
  64         bBEBZYk/v56xgdjMAtIS3343g9UIC/hLND1sZYEY2s8o0bfkNdjlnAJmEp/+fGOEWCAocXLm\r
  65         ExaIZhuJEz+2Ai3jABu0/B8HRFheYvvbOcwgtqiAucSDvTsYJzCKzULSPQtJ9yyE7llIuhcw\r
  66         sqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIiip2F6UdjD8PKh1iFOBgVOLh\r
  67         vcClECDEmlhWXJl7iFGSg0lJlLdERDFAiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv4Z1A5bwp\r
  68         iZVVqUX5MClpDhYlcd5rKTf9hQTSE0tSs1NTC1KLYLIyHBxKErxiwOQhJFiUmp5akZaZU4KQ\r
  69         ZuLgBBnOAzRcFqSGt7ggMbc4Mx0if4pRUUqclxUkIQCSyCjNg+uFJb1XjOJArwjz6oNU8QAT\r
  70         Jlz3K6DBTECDveXlQAaXJCKkpBoY9T+Jxi9WyBZRN5K7/8SaySTLIri/eF1HmP2p63mNKmkG\r
  71         jhaFr3ksXgS9fr9SJbxq/Z+nNoIGyi8ecHDu2NMy5Z1jLpNlmkhS7IGney4ppXEtnL1qIn/P\r
  72         0arZKacFN9dO2fdaO0j3rVh5DrvVuwwfli619C0e54psG2aqi127cfq82LfKk5JKLMUZiYZa\r
  73         zEXFiQD1UuH6VQMAAA==\r
  74 Cc: notmuch@notmuchmail.org\r
  75 X-BeenThere: notmuch@notmuchmail.org\r
  76 X-Mailman-Version: 2.1.13\r
  77 Precedence: list\r
  78 List-Id: "Use and development of the notmuch mail system."\r
  79         <notmuch.notmuchmail.org>\r
  80 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  81         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  82 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  83 List-Post: <mailto:notmuch@notmuchmail.org>\r
  84 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  85 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  86         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  87 X-List-Received-Date: Tue, 07 Aug 2012 13:57:35 -0000\r
  88 \r
  89 Quoting Peter Wang <novalazy@gmail.com>:\r
  90 > On Mon, 6 Aug 2012 12:47:10 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
  91 >> What's the overall goal of adding this?  Are you planning to add size\r
  92 >> information to one of the frontends?\r
  93 >\r
  94 > Yes, to my frontend.\r
  95 >\r
  96 >>> > diff --git a/devel/schemata b/devel/schemata\r
  97 >> > index 9cb25f5..3df2764 100644\r
  98 >> > --- a/devel/schemata\r
  99 >> > +++ b/devel/schemata\r
 100 >> > @@ -69,7 +69,10 @@ part = {\r
 101 >> >      # A leaf part's body content is optional, but may be included if\r
 102 >> >      # it can be correctly encoded as a string.  Consumers should use\r
 103 >> >      # this in preference to fetching the part content separately.\r
 104 >> > -    content?:       string\r
 105 >> > +    content?:       string,\r
 106 >> > +    # If a leaf part's body content is not included, the content-length\r
 107 >> > +    # may be included instead.\r
 108 >>\r
 109 >> You mentioned elsewhere that the content-length returned is an\r
 110 >> estimate.  If that's the case, this comment should say as much.  Is it\r
 111 >> actually the case, though?  g_mime_part_get_content_object is\r
 112 >> remarkably poorly documented for such an important function, but based\r
 113 >> on format_part_raw, it seems like the content-length your code returns\r
 114 >> will be exactly the number of bytes returned by the raw format for a\r
 115 >> leaf part.\r
 116 >\r
 117 > It's the exact length of the _encoded_ content.  If the transfer\r
 118 > encoding is base64, multiplying by 3/4 will get a close estimate of the\r
 119 > decoded content length.  I assume quoted-printable encoding would only\r
 120 > be used if the content is mostly ASCII, so the encoded length can serve\r
 121 > as the estimated decoded length then.\r
 122 \r
 123 Ah, I see.  format_part_raw misled me; apparently the\r
 124 g_mime_data_wrapper_write_to_stream is key there, since *that* decodes\r
 125 the transfer encoding of the data wrapper's underlying, raw stream.\r
 126 \r
 127 In that case, the comment could either mention that this is the length\r
 128 of the transfer encoded content or it could say it's an approximation\r
 129 of the decoded length.  The advantage of only claiming the latter is\r
 130 that it would leave open the possibility of, say, multiplying by .75\r
 131 for base64 transfer encoding to get a better decoded estimate (your\r
 132 assumption about quoted-printable sounds completely reasonable).\r
 133 Alternatively, we could add the transfer encoding in the future and\r
 134 let the caller do such approximations.\r
 135 \r
 136 >> > diff --git a/notmuch-show.c b/notmuch-show.c\r
 137 >> > index 3556293..5c54257 100644\r
 138 >> > --- a/notmuch-show.c\r
 139 >> > +++ b/notmuch-show.c\r
 140 >> > @@ -664,6 +664,14 @@ format_part_json (const void *ctx, sprinter_t \r
 141 >> *sp, mime_node_t *node,\r
 142 >> >        sp->map_key (sp, "content");\r
 143 >> >        sp->string_len (sp, (char *) part_content->data, part_content->len);\r
 144 >> >        g_object_unref (stream_memory);\r
 145 >> > +  } else {\r
 146 >> > +      GMimeDataWrapper *wrapper = g_mime_part_get_content_object \r
 147 >> (GMIME_PART (node->part));\r
 148 >> > +      GMimeStream *stream = g_mime_data_wrapper_get_stream (wrapper);\r
 149 >> > +      ssize_t length = g_mime_stream_length (stream);\r
 150 >> > +      if (length >= 0) {\r
 151 >> > +          sp->map_key (sp, "content-length");\r
 152 >> > +          sp->integer (sp, length);\r
 153 >> > +      }\r
 154 >>\r
 155 >> Do wrapper or stream need to be g_object_unref'd?\r
 156 >\r
 157 > No.\r
 158 >\r
 159 >> Any idea what the performance overhead of this is?  I'm just curious.\r
 160 >> It might be approximately nothing, since GMime's parser is eager.\r
 161 >\r
 162 > The start and end bounds of the stream are already known so there's\r
 163 > approximately nothing for g_mime_stream_length to do.  The other\r
 164 > functions simply return field values.\r
 165 \r
 166 Sounds good.\r
 167 \r
 168 > I'll drop the changes for text output.\r
 169 >\r
 170 > Peter\r
 171 \r