--- /dev/null
+Return-Path: <amdragon@mit.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id B9A7A41ED7F\r
+ for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 16:36:24 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id eQ2OJCKlPiWU for <notmuch@notmuchmail.org>;\r
+ Sat, 14 Jan 2012 16:36:23 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU\r
+ [18.7.68.34])\r
+ by olra.theworths.org (Postfix) with ESMTP id A7E4D41ED72\r
+ for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 16:36:23 -0800 (PST)\r
+X-AuditID: 12074422-b7fd66d0000008f9-8d-4f121f87de7d\r
+Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])\r
+ by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id 2A.C3.02297.78F121F4; Sat, 14 Jan 2012 19:36:23 -0500 (EST)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+ by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q0F0aNwJ001178; \r
+ Sat, 14 Jan 2012 19:36:23 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0F0aKLv028990\r
+ (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+ Sat, 14 Jan 2012 19:36:21 -0500 (EST)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1RmE53-0002MA-Cg; Sat, 14 Jan 2012 19:36:17 -0500\r
+Date: Sat, 14 Jan 2012 19:36:17 -0500\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: notmuch@notmuchmail.org, Pieter Praet <pieter@praet.org>\r
+Subject: The overloading of show (was Re: [PATCH] Output unmodified\r
+ Content-Type header value for JSON format.)\r
+Message-ID: <20120115003617.GH1801@mit.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IRYrdT122XF/I3eL1ZyOLq1n52iz37vCyu\r
+ 35zJbPH79Q1mBxaPu6e5PHbOusvu8WzVLWaPjn2XWQNYorhsUlJzMstSi/TtErgyTk/uZy64\r
+ r1xxYWMHWwPjCZkuRg4OCQETiasN1l2MnECmmMSFe+vZuhi5OIQE9jFKTGpoYYZwNjBKzLj9\r
+ H8o5ySTx+M1uJghnCaPE/ym72ED6WQRUJRauPc4OYrMJaEhs27+cEcQWEbCRuDZjGguIzSyQ\r
+ J3G+YQkriC0sUCgxdcFzdpAzeAW0JRZeqgEJ8woISpyc+QSqXEvixr+XTCAlzALSEsv/cYCE\r
+ RQVUJKac3MY2gVFgFpKOWUg6ZiF0LGBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKX\r
+ mlK6iREcyC5KOxh/HlQ6xCjAwajEw1uYI+AvxJpYVlyZe4hRkoNJSZT3g5yQvxBfUn5KZUZi\r
+ cUZ8UWlOavEhRgkOZiUR3gWsQDnelMTKqtSifJiUNAeLkjivutY7PyGB9MSS1OzU1ILUIpis\r
+ DAeHkgTvF5ChgkWp6akVaZk5JQhpJg5OkOE8QMPfgtTwFhck5hZnpkPkTzHqcpxce+UcoxBL\r
+ Xn5eqpQ47yGQIgGQoozSPLg5sAT0ilEc6C1h3q0gVTzA5AU36RXQEiagJWUpfCBLShIRUlIN\r
+ jFOORggwhsxznJ23rkzrp4Vw5JL5CsZaGlHeB3NzMqY3dz7uLL67sVFcTODuMR2RwrBdV1I/\r
+ 392xMnen3v/L9rN6J6srBbFtN9w4J7eluru1w+xJ2oeFh20+M1zYOjv56JsTgtJvs3VLDonJ\r
+ S816JeV9+ODf2KcMByX+tjv4Fvw/Kv/F4NmL10osxRmJhlrMRcWJADB5/ZkbAwAA\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 15 Jan 2012 00:36:24 -0000\r
+\r
+(was in reply to id:87ehv2proa.fsf@praet.org, but I wanted to start a\r
+new top-level thread)\r
+\r
+Quoth Pieter Praet on Jan 14 at 10:19 am:\r
+> On Thu, 12 Jan 2012 12:28:40 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> > Quoth Pieter Praet on Jan 12 at 6:07 pm:\r
+> > > On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> > > > Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:\r
+> > > > > The open question seems to be how we handle the content encoding\r
+> > > > > parameters. My argument is that those should either be used by notmuch\r
+> > > > > to properly encode the content for the consumer. If that's not\r
+> > > > > possible, then just those parameters needed by the consumer to decode\r
+> > > > > the content should be output.\r
+> > > > \r
+> > > > If notmuch is going to include part content in the JSON output (which\r
+> > > > perhaps it shouldn't, as per recent IRC discussions), then it must\r
+> > > > handle content encodings because JSON must be Unicode and therefore\r
+> > > > the content strings in the JSON must be Unicode.\r
+> > > \r
+> > > Having missed the IRC discussions: what is the rationale for not\r
+> > > including (specific types of?) part content in the JSON output ?\r
+> > > Eg. how about inline attached text/x-patch ?\r
+> > \r
+> > Technically the IRC discussion was about not including *any* part\r
+> > content in the JSON output, and always using show --format=raw or\r
+> > similar to retrieve desired parts. Currently, notmuch includes part\r
+> > content in the JSON only for text/*, *except* when it's text/html. I\r
+> > assume non-text parts are omitted because binary data is hard to\r
+> > represent in JSON and text/html is omitted because some people don't\r
+> > need it. However, this leads to some peculiar asymmetry in the Emacs\r
+> > code where sometimes it pulls part content out of the JSON and\r
+> > sometimes it retrieves it using show --format=raw. This in turn leads\r
+> > to asymmetry in content encoding handling, since notmuch handles\r
+> > content encoding for parts included in the JSON (and there's no good\r
+> > way around that since JSON is Unicode), but not for parts retrieved as\r
+> > raw.\r
+> > \r
+> > The idea discussed on IRC was to remove all part content from the JSON\r
+> > output and to always use show to retrieve it, possibly beefing up\r
+> > show's support for content decoding (and possibly introducing a way to\r
+> > retrieve multiple raw parts at once to avoid re-parsing). This would\r
+> > get the JSON format out of the business of guessing what consumers\r
+> > need, simplify the Emacs code, and normalize content encoding\r
+> > handling.\r
+> \r
+> Full ACK.\r
+> \r
+> One concern though (IIUC): Due to the prevalence of retarded MUA's, not\r
+> outputting 'text/plain' and/or 'text/html' parts is unfortunately all\r
+> too often equivalent to not outputting anything at all, so wouldn't we,\r
+> in essence, be reducing `show --format=json' to an ever-so-slightly\r
+> augmented `search --format=json' ?\r
+\r
+I'm not sure I fully understand what you're saying, but there are\r
+several levels of structure here:\r
+\r
+1. Threads (query results)\r
+2. Thread structure\r
+3. Message structure (MIME)\r
+4. Part content\r
+\r
+Currently, search returns 1; show --format=json returns 2, 3, and\r
+sometimes 4 (but sometimes not); and show --format=raw returns 4.\r
+Notably, 1 does not require opening message files (neither does 2),\r
+which I consider an important distinction between search and show.\r
+\r
+Some of the discussion has been about putting 4 squarely in the realm\r
+of show --format=raw. One counterargument (which has grown on me\r
+since this discussion) is that the part content included in\r
+--format=json can be thought of as pre-fetching content that clients\r
+are likely to need in order to avoid re-parsing the message in most\r
+circumstances. I believe this is not the *intent* of the current\r
+code, though without a specification of the JSON format it's hard to\r
+tell.\r
+\r
+Other discussion (more interesting, in my mind) has been about\r
+separating retrieving thread structure, 2, from retrieving message\r
+structure, 3. To me, splitting these feels much more natural than\r
+what we do now, which seems to be inflexibly bound to the specific way\r
+the Emacs show mode currently works. The thread structure is readily\r
+available from the database, so I think separating these would open up\r
+some new UI opportunities, particularly easy and fast thread outlining\r
+and navigation. I believe it would also simplify the code and address\r
+some irritating asymmetries in the way notmuch show handles the --part\r
+argument.\r
projects / notmuch-archives.git / commitdiff