84/4e507c0d8392b0fe3cef7759532d9233553631

   1 Return-Path: <cworth@cworth.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 0E5E9429E2D\r
   6         for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 14:02:59 -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.99\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] 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 SAEhihIetwXd; Fri, 28 Jan 2011 14:02:57 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id 20741429E23;\r
  18         Fri, 28 Jan 2011 14:02:53 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 010672540E0; Sat, 29 Jan 2011 06:40:08 +1000 (EST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Christophe-Marie Duquesne <chm.duquesne@gmail.com>,\r
  23  notmuch@notmuchmail.org\r
  24 Subject: Re: About the json output and the number of results shown.\r
  25 In-Reply-To: <AANLkTi=Mzu9bu3y0RKB5YZUpZOT9qujXgxtpB-8Bvk=2@mail.gmail.com>\r
  26 References: <AANLkTi=Mzu9bu3y0RKB5YZUpZOT9qujXgxtpB-8Bvk=2@mail.gmail.com>\r
  27 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1\r
  28         (i486-pc-linux-gnu)\r
  29 Date: Sat, 29 Jan 2011 06:40:08 +1000\r
  30 Message-ID: <87pqrgn4nr.fsf@yoom.home.cworth.org>\r
  31 MIME-Version: 1.0\r
  32 Content-Type: multipart/signed; boundary="=-=-=";\r
  33         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  34 X-BeenThere: notmuch@notmuchmail.org\r
  35 X-Mailman-Version: 2.1.13\r
  36 Precedence: list\r
  37 List-Id: "Use and development of the notmuch mail system."\r
  38         <notmuch.notmuchmail.org>\r
  39 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  41 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  42 List-Post: <mailto:notmuch@notmuchmail.org>\r
  43 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  44 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  46 X-List-Received-Date: Fri, 28 Jan 2011 22:02:59 -0000\r
  47 \r
  48 --=-=-=\r
  49 Content-Transfer-Encoding: quoted-printable\r
  50 \r
  51 On Wed, 12 Jan 2011 19:37:21 +0100, Christophe-Marie Duquesne <chm.duquesne=\r
  52 @gmail.com> wrote:\r
  53 > So I am wondering: what is the point of having a tool that is able to\r
  54 > output json and ending in not using it? Is there a solution to make\r
  55 > the json output more useable? One solution I've been thinking about\r
  56 > would be to add an option: the range of results to show (something\r
  57 > like --range=3D25:50). Is it doable easily?\r
  58 \r
  59 This is fairly easy to do, yes. We even had functionality like this\r
  60 once, and I'll probably even add it back soon, (since a client like the\r
  61 vim interface isn't able to do the kind of asynchronous processing that\r
  62 you would really want).\r
  63 \r
  64 One problem with the ranged output (for "notmuch search" at least) is\r
  65 that small ranges with large initial offsets will take longer than\r
  66 expected. This is because in this case notmuch can't directly use\r
  67 Xapian's range offset support. The user is asking for an offset as a\r
  68 number of threads, but within Xapian we only have messages stored. So\r
  69 notmuch will have to search for messages from the beginning, construct a\r
  70 bunch of useless threads, and then throw those threads away after doing\r
  71 no more than counting them.\r
  72 \r
  73 This inefficiency in this API was one of the reasons I dropped this\r
  74 functionality before. It's pretty ugly. But I don't see a really good\r
  75 answer for that.\r
  76 \r
  77 > feature request. In any case, do you have any proposal for making\r
  78 > sense of this json output without modifications in the notmuch CLI?\r
  79 \r
  80 We've run into basically the same issue with the emacs interface. We've\r
  81 been avoiding using the json output precisely because the emacs JSON\r
  82 parsing would need to see all the output before it could start\r
  83 parsing. And that wouldn't give us the responsive user interface that we\r
  84 want.\r
  85 \r
  86 One idea I've had for this is to change the output (perhaps with a\r
  87 command-line option) to avoid emitting the outer array. That is, the\r
  88 results would instead be a series of independent JSON objects rather\r
  89 than a single JSON object. That should let the application treat things\r
  90 quickly by simply calling the JSON parser for each complete\r
  91 object. (Though, here, the application would likely want a cheap way to\r
  92 know when the input represented a complete object.)\r
  93 \r
  94 If anyone wants to help improve our JSON output here, then that would be\r
  95 great.\r
  96 \r
  97 For any change to the structure of the JSON output, I'd also like to see\r
  98 some documentation added to specify that structure clearly.\r
  99 \r
 100 =2DCarl\r
 101 \r
 102 =2D-=20\r
 103 carl.d.worth@intel.com\r
 104 \r
 105 --=-=-=\r
 106 Content-Type: application/pgp-signature\r
 107 \r
 108 -----BEGIN PGP SIGNATURE-----\r
 109 Version: GnuPG v1.4.10 (GNU/Linux)\r
 110 \r
 111 iD8DBQFNQymo6JDdNq8qSWgRAsk/AJ9lEGyf/Gzzwc90+J6CGgxuXGWQTgCfYR8Z\r
 112 M/ZC0NrBeU2AIvakTZ1vhYc=\r
 113 =pCZi\r
 114 -----END PGP SIGNATURE-----\r
 115 --=-=-=--\r