9b/89c07cad3f0fce2ec699ae7d09ff88799999ab

   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 B9A7A41ED7F\r
   6         for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 16:36:24 -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 eQ2OJCKlPiWU for <notmuch@notmuchmail.org>;\r
  16         Sat, 14 Jan 2012 16:36:23 -0800 (PST)\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 A7E4D41ED72\r
  20         for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 16:36:23 -0800 (PST)\r
  21 X-AuditID: 12074422-b7fd66d0000008f9-8d-4f121f87de7d\r
  22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])\r
  23         by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 2A.C3.02297.78F121F4; Sat, 14 Jan 2012 19:36:23 -0500 (EST)\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 q0F0aNwJ001178; \r
  27         Sat, 14 Jan 2012 19:36:23 -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 q0F0aKLv028990\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sat, 14 Jan 2012 19:36:21 -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 1RmE53-0002MA-Cg; Sat, 14 Jan 2012 19:36:17 -0500\r
  37 Date: Sat, 14 Jan 2012 19:36:17 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: notmuch@notmuchmail.org, Pieter Praet <pieter@praet.org>\r
  40 Subject: The overloading of show (was Re: [PATCH] Output unmodified\r
  41         Content-Type header value for JSON format.)\r
  42 Message-ID: <20120115003617.GH1801@mit.edu>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: text/plain; charset=us-ascii\r
  45 Content-Disposition: inline\r
  46 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  47 X-Brightmail-Tracker:\r
  48  H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IRYrdT122XF/I3eL1ZyOLq1n52iz37vCyu\r
  49         35zJbPH79Q1mBxaPu6e5PHbOusvu8WzVLWaPjn2XWQNYorhsUlJzMstSi/TtErgyTk/uZy64\r
  50         r1xxYWMHWwPjCZkuRg4OCQETiasN1l2MnECmmMSFe+vZuhi5OIQE9jFKTGpoYYZwNjBKzLj9\r
  51         H8o5ySTx+M1uJghnCaPE/ym72ED6WQRUJRauPc4OYrMJaEhs27+cEcQWEbCRuDZjGguIzSyQ\r
  52         J3G+YQkriC0sUCgxdcFzdpAzeAW0JRZeqgEJ8woISpyc+QSqXEvixr+XTCAlzALSEsv/cYCE\r
  53         RQVUJKac3MY2gVFgFpKOWUg6ZiF0LGBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKX\r
  54         mlK6iREcyC5KOxh/HlQ6xCjAwajEw1uYI+AvxJpYVlyZe4hRkoNJSZT3g5yQvxBfUn5KZUZi\r
  55         cUZ8UWlOavEhRgkOZiUR3gWsQDnelMTKqtSifJiUNAeLkjivutY7PyGB9MSS1OzU1ILUIpis\r
  56         DAeHkgTvF5ChgkWp6akVaZk5JQhpJg5OkOE8QMPfgtTwFhck5hZnpkPkTzHqcpxce+UcoxBL\r
  57         Xn5eqpQ47yGQIgGQoozSPLg5sAT0ilEc6C1h3q0gVTzA5AU36RXQEiagJWUpfCBLShIRUlIN\r
  58         jFOORggwhsxznJ23rkzrp4Vw5JL5CsZaGlHeB3NzMqY3dz7uLL67sVFcTODuMR2RwrBdV1I/\r
  59         392xMnen3v/L9rN6J6srBbFtN9w4J7eluru1w+xJ2oeFh20+M1zYOjv56JsTgtJvs3VLDonJ\r
  60         S816JeV9+ODf2KcMByX+tjv4Fvw/Kv/F4NmL10osxRmJhlrMRcWJADB5/ZkbAwAA\r
  61 X-BeenThere: notmuch@notmuchmail.org\r
  62 X-Mailman-Version: 2.1.13\r
  63 Precedence: list\r
  64 List-Id: "Use and development of the notmuch mail system."\r
  65         <notmuch.notmuchmail.org>\r
  66 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  67         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  68 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  69 List-Post: <mailto:notmuch@notmuchmail.org>\r
  70 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  71 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  73 X-List-Received-Date: Sun, 15 Jan 2012 00:36:24 -0000\r
  74 \r
  75 (was in reply to id:87ehv2proa.fsf@praet.org, but I wanted to start a\r
  76 new top-level thread)\r
  77 \r
  78 Quoth Pieter Praet on Jan 14 at 10:19 am:\r
  79 > On Thu, 12 Jan 2012 12:28:40 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
  80 > > Quoth Pieter Praet on Jan 12 at  6:07 pm:\r
  81 > > > On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
  82 > > > > Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:\r
  83 > > > > > The open question seems to be how we handle the content encoding\r
  84 > > > > > parameters.  My argument is that those should either be used by notmuch\r
  85 > > > > > to properly encode the content for the consumer.  If that's not\r
  86 > > > > > possible, then just those parameters needed by the consumer to decode\r
  87 > > > > > the content should be output.\r
  88 > > > > \r
  89 > > > > If notmuch is going to include part content in the JSON output (which\r
  90 > > > > perhaps it shouldn't, as per recent IRC discussions), then it must\r
  91 > > > > handle content encodings because JSON must be Unicode and therefore\r
  92 > > > > the content strings in the JSON must be Unicode.\r
  93 > > > \r
  94 > > > Having missed the IRC discussions: what is the rationale for not\r
  95 > > > including (specific types of?) part content in the JSON output ?\r
  96 > > > Eg. how about inline attached text/x-patch ?\r
  97 > > \r
  98 > > Technically the IRC discussion was about not including *any* part\r
  99 > > content in the JSON output, and always using show --format=raw or\r
 100 > > similar to retrieve desired parts.  Currently, notmuch includes part\r
 101 > > content in the JSON only for text/*, *except* when it's text/html.  I\r
 102 > > assume non-text parts are omitted because binary data is hard to\r
 103 > > represent in JSON and text/html is omitted because some people don't\r
 104 > > need it.  However, this leads to some peculiar asymmetry in the Emacs\r
 105 > > code where sometimes it pulls part content out of the JSON and\r
 106 > > sometimes it retrieves it using show --format=raw.  This in turn leads\r
 107 > > to asymmetry in content encoding handling, since notmuch handles\r
 108 > > content encoding for parts included in the JSON (and there's no good\r
 109 > > way around that since JSON is Unicode), but not for parts retrieved as\r
 110 > > raw.\r
 111 > > \r
 112 > > The idea discussed on IRC was to remove all part content from the JSON\r
 113 > > output and to always use show to retrieve it, possibly beefing up\r
 114 > > show's support for content decoding (and possibly introducing a way to\r
 115 > > retrieve multiple raw parts at once to avoid re-parsing).  This would\r
 116 > > get the JSON format out of the business of guessing what consumers\r
 117 > > need, simplify the Emacs code, and normalize content encoding\r
 118 > > handling.\r
 119 > \r
 120 > Full ACK.\r
 121 > \r
 122 > One concern though (IIUC): Due to the prevalence of retarded MUA's, not\r
 123 > outputting 'text/plain' and/or 'text/html' parts is unfortunately all\r
 124 > too often equivalent to not outputting anything at all, so wouldn't we,\r
 125 > in essence, be reducing `show --format=json' to an ever-so-slightly\r
 126 > augmented `search --format=json' ?\r
 127 \r
 128 I'm not sure I fully understand what you're saying, but there are\r
 129 several levels of structure here:\r
 130 \r
 131 1. Threads (query results)\r
 132 2. Thread structure\r
 133 3. Message structure (MIME)\r
 134 4. Part content\r
 135 \r
 136 Currently, search returns 1; show --format=json returns 2, 3, and\r
 137 sometimes 4 (but sometimes not); and show --format=raw returns 4.\r
 138 Notably, 1 does not require opening message files (neither does 2),\r
 139 which I consider an important distinction between search and show.\r
 140 \r
 141 Some of the discussion has been about putting 4 squarely in the realm\r
 142 of show --format=raw.  One counterargument (which has grown on me\r
 143 since this discussion) is that the part content included in\r
 144 --format=json can be thought of as pre-fetching content that clients\r
 145 are likely to need in order to avoid re-parsing the message in most\r
 146 circumstances.  I believe this is not the *intent* of the current\r
 147 code, though without a specification of the JSON format it's hard to\r
 148 tell.\r
 149 \r
 150 Other discussion (more interesting, in my mind) has been about\r
 151 separating retrieving thread structure, 2, from retrieving message\r
 152 structure, 3.  To me, splitting these feels much more natural than\r
 153 what we do now, which seems to be inflexibly bound to the specific way\r
 154 the Emacs show mode currently works.  The thread structure is readily\r
 155 available from the database, so I think separating these would open up\r
 156 some new UI opportunities, particularly easy and fast thread outlining\r
 157 and navigation.  I believe it would also simplify the code and address\r
 158 some irritating asymmetries in the way notmuch show handles the --part\r
 159 argument.\r