bc/6aebfa969e1e26359bf08d9a1b3c80e2e14b9a

   1 Return-Path: <dme@dme.org>\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 981FE431FC9\r
   6         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:50:54 -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 kbDLWPQihOLC for <notmuch@notmuchmail.org>;\r
  16         Mon, 16 Jan 2012 05:50:53 -0800 (PST)\r
  17 Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com\r
  18  [74.125.82.45])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  19  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  20  4D729431FAE    for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:50:53 -0800\r
  21  (PST)\r
  22 Received: by wgbdr13 with SMTP id dr13so220981wgb.2\r
  23         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:50:52 -0800 (PST)\r
  24 Received: by 10.180.102.169 with SMTP id fp9mr20022551wib.9.1326721851567;\r
  25         Mon, 16 Jan 2012 05:50:51 -0800 (PST)\r
  26 Received: from hotblack-desiato.hh.sledj.net\r
  27         (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25])\r
  28         by mx.google.com with ESMTPS id ev11sm6851363wbb.2.2012.01.16.05.50.49\r
  29         (version=TLSv1/SSLv3 cipher=OTHER);\r
  30         Mon, 16 Jan 2012 05:50:50 -0800 (PST)\r
  31 Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000)\r
  32         id EC944A0397; Mon, 16 Jan 2012 13:50:46 +0000 (GMT)\r
  33 To: Austin Clements <amdragon@MIT.EDU>\r
  34 Subject: Re: The overloading of show (was Re: [PATCH] Output unmodified\r
  35         Content-Type header value for JSON format.)\r
  36 In-Reply-To: <20120115003617.GH1801@mit.edu>\r
  37 References: <20120115003617.GH1801@mit.edu>\r
  38 User-Agent: Notmuch/0.11+64~g42e8f66 (http://notmuchmail.org) Emacs/24.0.92.1\r
  39         (x86_64-pc-linux-gnu)\r
  40 From: David Edmondson <dme@dme.org>\r
  41 Date: Mon, 16 Jan 2012 13:50:43 +0000\r
  42 Message-ID: <cunaa5nu570.fsf@hotblack-desiato.hh.sledj.net>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: multipart/signed; boundary="=-=-=";\r
  45         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  46 Cc: notmuch <notmuch@notmuchmail.org>\r
  47 X-BeenThere: notmuch@notmuchmail.org\r
  48 X-Mailman-Version: 2.1.13\r
  49 Precedence: list\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51         <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Mon, 16 Jan 2012 13:50:54 -0000\r
  60 \r
  61 --=-=-=\r
  62 Content-Type: text/plain\r
  63 Content-Transfer-Encoding: quoted-printable\r
  64 \r
  65 On Sat, 14 Jan 2012 19:36:17 -0500, Austin Clements <amdragon@MIT.EDU> wrot=\r
  66 e:\r
  67 > ...there are several levels of structure here:\r
  68 >=20\r
  69 > 1. Threads (query results)\r
  70 > 2. Thread structure\r
  71 > 3. Message structure (MIME)\r
  72 > 4. Part content\r
  73 >=20\r
  74 > Currently, search returns 1; show --format=3Djson returns 2, 3, and\r
  75 > sometimes 4 (but sometimes not); and show --format=3Draw returns 4.\r
  76 > Notably, 1 does not require opening message files (neither does 2),\r
  77 > which I consider an important distinction between search and show.\r
  78 >=20\r
  79 > Some of the discussion has been about putting 4 squarely in the realm\r
  80 > of show --format=3Draw.  One counterargument (which has grown on me\r
  81 > since this discussion) is that the part content included in\r
  82 > --format=3Djson can be thought of as pre-fetching content that clients\r
  83 > are likely to need in order to avoid re-parsing the message in most\r
  84 > circumstances.  I believe this is not the *intent* of the current\r
  85 > code, though without a specification of the JSON format it's hard to\r
  86 > tell.\r
  87 \r
  88 The JSON output included what was considered useful (mostly for the\r
  89 Emacs UI), but how much deep thought went into 'useful' I couldn't say.\r
  90 \r
  91 > Other discussion (more interesting, in my mind) has been about\r
  92 > separating retrieving thread structure, 2, from retrieving message\r
  93 > structure, 3.  To me, splitting these feels much more natural than\r
  94 > what we do now, which seems to be inflexibly bound to the specific way\r
  95 > the Emacs show mode currently works.  The thread structure is readily\r
  96 > available from the database, so I think separating these would open up\r
  97 > some new UI opportunities, particularly easy and fast thread outlining\r
  98 > and navigation.\r
  99 \r
 100 Given that the current output already includes both 2 and 3, anything\r
 101 that could be done with 2 can be done with the current output, so\r
 102 there's no block on the kind of innovation that you describe other than\r
 103 possibly some performance problems.\r
 104 \r
 105 notmuch-lkml.el[1] was a quick prototype of an alternative way to find\r
 106 messages to read based on suggestions from Aneesh. It could have used\r
 107 the proposed 'thread structure only' output.\r
 108 \r
 109 The changes you allude to make sense. My only concern would be any\r
 110 potential impact on the current Emacs UI's use of JSON output. Switching\r
 111 to a model where a typical 'notmuch-show' buffer requires many calls to\r
 112 notmuch (and commensurate JSON parsing) may perform significantly worse\r
 113 than the current approach.\r
 114 \r
 115 > I believe it would also simplify the code and address some irritating\r
 116 > asymmetries in the way notmuch show handles the --part argument.\r
 117 \r
 118 Footnotes:=20\r
 119 [1]  http://dme.org/data/emacs/notmuch-lkml.el\r
 120 \r
 121 \r
 122 --=-=-=\r
 123 Content-Type: application/pgp-signature\r
 124 \r
 125 -----BEGIN PGP SIGNATURE-----\r
 126 Version: GnuPG v1.4.11 (GNU/Linux)\r
 127 \r
 128 iEYEARECAAYFAk8UKzMACgkQaezQq/BJZRbBxACcCg61tuL9eLvxrXrIiWL3OVTb\r
 129 JP8AnibEvGhy4wRtAZyEZHvaNHgYSJDJ\r
 130 =GQP7\r
 131 -----END PGP SIGNATURE-----\r
 132 --=-=-=--\r