75/77d675d8ea13a295802ec8489c744d2b46464f

   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 F273B431FB6\r
   6         for <notmuch@notmuchmail.org>; Sun, 15 Jan 2012 09:58:51 -0800 (PST)\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 UzoPe-SEmP+w for <notmuch@notmuchmail.org>;\r
  16         Sun, 15 Jan 2012 09:58:51 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU\r
  18         [18.9.25.14])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 3C9B5431FAE\r
  20         for <notmuch@notmuchmail.org>; Sun, 15 Jan 2012 09:58:51 -0800 (PST)\r
  21 X-AuditID: 1209190e-b7f7c6d0000008c3-f9-4f1313d9daa4\r
  22 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
  23         by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 93.14.02243.9D3131F4; Sun, 15 Jan 2012 12:58:49 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q0FHwmM6018515; \r
  27         Sun, 15 Jan 2012 12:58:49 -0500\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 q0FHwkCB009904\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sun, 15 Jan 2012 12:58:47 -0500 (EST)\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 1RmULo-0003y8-VY; Sun, 15 Jan 2012 12:58:41 -0500\r
  37 From: Austin Clements <amdragon@MIT.EDU>\r
  38 To: David Edmondson <dme@dme.org>, Pieter Praet <pieter@praet.org>\r
  39 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
  40         format.\r
  41 In-Reply-To: <cun1ur16v3r.fsf@hotblack-desiato.hh.sledj.net>\r
  42 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
  43         <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>\r
  44         <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>\r
  45         <87ipmewo4z.fsf@servo.finestructure.net>\r
  46         <20111123034021.GL9351@mit.edu> <87ipkglui4.fsf@praet.org>\r
  47         <20120112172840.GC18625@mit.edu> <87ehv2proa.fsf@praet.org>\r
  48         <cun1ur16v3r.fsf@hotblack-desiato.hh.sledj.net>\r
  49 User-Agent: Notmuch/0.10.2+133~g9e35ff5 (http://notmuchmail.org) Emacs/23.3.1\r
  50         (i486-pc-linux-gnu)\r
  51 Date: Sun, 15 Jan 2012 12:58:40 -0500\r
  52 Message-ID: <87boq4q23z.fsf@awakening.csail.mit.edu>\r
  53 MIME-Version: 1.0\r
  54 Content-Type: text/plain; charset=us-ascii\r
  55 X-Brightmail-Tracker:\r
  56  H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrHtTWNjf4PNZU4t9d7YwWVy/OZPZ\r
  57         4vfrG8wOzB67nv9l8ni26hazR8e+y6wBzFFcNimpOZllqUX6dglcGUcPdzAWXJao6G1IbGB8\r
  58         IdzFyMkhIWAi8bR3FyOELSZx4d56ti5GLg4hgX2MEjsuTmSCcDYwSmx7vpAVwjnJJLH1z29G\r
  59         CGcJo8Tn2dPA+tkENCS27V8OZosIOElsW/SVCcRmFpCW+Pa7GcwWFgiUWAJ0BojNKWAjcfDM\r
  60         eqhBi5glHt+6zgKSEBVIlJg1r5UdxGYRUJW4vfkUWJwX6NgdfedYIWxBiZMzn7BALNCSuPHv\r
  61         JdMERsFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECA5gSb4d\r
  62         jF8PKh1iFOBgVOLhFVIV8hdiTSwrrsw9xCjJwaQkyssDDH8hvqT8lMqMxOKM+KLSnNTiQ4wS\r
  63         HMxKIryVfEA53pTEyqrUonyYlDQHi5I4r5rWOz8hgfTEktTs1NSC1CKYrAwHh5IEryfIUMGi\r
  64         1PTUirTMnBKENBMHJ8hwHqDhdUIgw4sLEnOLM9Mh8qcYFaXEeeVAmgVAEhmleXC9sATzilEc\r
  65         6BVhXmeQKh5gcoLrfgU0mAlocE6rEMjgkkSElFQDo/SKf20zGULvLbg8J6bmUvjRkuPTTiy1\r
  66         YbjjGpCg3BL1n+m0zKbFTk+27308Wfy95a0rzfpdIpMuVq/YeIPJNTojmlMtmYV/itkVx/PT\r
  67         axdapQbI7AvYVbjRNlxS4tT/j+2y6z826PTutnsReTwxIPWTm/cG4TWtmyW/1s59x3DnCZ97\r
  68         vMCCSUosxRmJhlrMRcWJAIppEa8LAwAA\r
  69 Cc: notmuch@notmuchmail.org\r
  70 X-BeenThere: notmuch@notmuchmail.org\r
  71 X-Mailman-Version: 2.1.13\r
  72 Precedence: list\r
  73 List-Id: "Use and development of the notmuch mail system."\r
  74         <notmuch.notmuchmail.org>\r
  75 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  77 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  78 List-Post: <mailto:notmuch@notmuchmail.org>\r
  79 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  80 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  81         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  82 X-List-Received-Date: Sun, 15 Jan 2012 17:58:52 -0000\r
  83 \r
  84 On Sun, 15 Jan 2012 11:52:40 +0000, David Edmondson <dme@dme.org> wrote:\r
  85 > > Technically the IRC discussion was about not including *any* part\r
  86 > > content in the JSON output, and always using show --format=raw or\r
  87 > > similar to retrieve desired parts.  Currently, notmuch includes part\r
  88 > > content in the JSON only for text/*, *except* when it's text/html.  I\r
  89 > > assume non-text parts are omitted because binary data is hard to\r
  90 > > represent in JSON and text/html is omitted because some people don't\r
  91 > > need it.  However, this leads to some peculiar asymmetry in the Emacs\r
  92 > > code where sometimes it pulls part content out of the JSON and\r
  93 > > sometimes it retrieves it using show --format=raw.  This in turn leads\r
  94 > > to asymmetry in content encoding handling, since notmuch handles\r
  95 > > content encoding for parts included in the JSON (and there's no good\r
  96 > > way around that since JSON is Unicode), but not for parts retrieved as\r
  97 > > raw.\r
  98 > \r
  99 > Including the text output in the JSON results in significantly fewer\r
 100 > calls to 'notmuch' during the building of a typical `notmuch-show-mode'\r
 101 > buffer. Someone with one of those older, crankier computers could easily\r
 102 > test how much effect this has by changing\r
 103 > `notmuch-show-get-bodypart-content' slightly.\r
 104 \r
 105 Yes.  I was mostly reiterating the IRC discussion for Pieter.  Since\r
 106 this discussion, I've stabilized on the pre-fetching notion I described\r
 107 in id:"20120115003617.GH1801@mit.edu", though I do think we should make\r
 108 this clear in the code: that the rule for whether the JSON includes a\r
 109 "content" key for a leaf part is internal to the CLI and that consumers\r
 110 should be prepared to use it if it's there and to retrieve the content\r
 111 separately if it's not.  This is exactly how the Emacs code happens to\r
 112 work, it just hasn't been codified anywhere.  Looking at it this way\r
 113 gives us more flexibility than the current code takes advantage of; for\r
 114 example we could omit content from the JSON if it's over some size\r
 115 threshold since the cost of sending that to a client that doesn't need\r
 116 it is high while the cost of having the client retrieve it for itself is\r
 117 relatively low.\r
 118 \r
 119 > > The idea discussed on IRC was to remove all part content from the JSON\r
 120 > > output and to always use show to retrieve it, possibly beefing up\r
 121 > > show's support for content decoding (and possibly introducing a way to\r
 122 > > retrieve multiple raw parts at once to avoid re-parsing).  This would\r
 123 > > get the JSON format out of the business of guessing what consumers\r
 124 > > need, simplify the Emacs code, and normalize content encoding\r
 125 > > handling.\r
 126 > \r
 127 > Is there a real problem being solved here? Having a clean structure is\r
 128 > nice, except when it's not.\r
 129 \r
 130 The "real" problem is the asymmetry in encoding handling that started\r
 131 this discussion.  Content included in the JSON is re-encoded by the CLI,\r
 132 while content retrieved via raw needs to be re-encoded by the client.\r
 133 \r
 134 OTOH, I don't understand the encoding story for HTML, since the encoding\r
 135 can come from either a header or from the body of the HTML.  Does this\r
 136 make it strictly necessary for the client to handle the encoding?\r