From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 0E5E9429E2D for ; Fri, 28 Jan 2011 14:02:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAEhihIetwXd; Fri, 28 Jan 2011 14:02:57 -0800 (PST) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 20741429E23; Fri, 28 Jan 2011 14:02:53 -0800 (PST) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id 010672540E0; Sat, 29 Jan 2011 06:40:08 +1000 (EST) From: Carl Worth To: Christophe-Marie Duquesne , notmuch@notmuchmail.org Subject: Re: About the json output and the number of results shown. In-Reply-To: References: User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Sat, 29 Jan 2011 06:40:08 +1000 Message-ID: <87pqrgn4nr.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 22:02:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, 12 Jan 2011 19:37:21 +0100, Christophe-Marie Duquesne wrote: > So I am wondering: what is the point of having a tool that is able to > output json and ending in not using it? Is there a solution to make > the json output more useable? One solution I've been thinking about > would be to add an option: the range of results to show (something > like --range=3D25:50). Is it doable easily? This is fairly easy to do, yes. We even had functionality like this once, and I'll probably even add it back soon, (since a client like the vim interface isn't able to do the kind of asynchronous processing that you would really want). One problem with the ranged output (for "notmuch search" at least) is that small ranges with large initial offsets will take longer than expected. This is because in this case notmuch can't directly use Xapian's range offset support. The user is asking for an offset as a number of threads, but within Xapian we only have messages stored. So notmuch will have to search for messages from the beginning, construct a bunch of useless threads, and then throw those threads away after doing no more than counting them. This inefficiency in this API was one of the reasons I dropped this functionality before. It's pretty ugly. But I don't see a really good answer for that. > feature request. In any case, do you have any proposal for making > sense of this json output without modifications in the notmuch CLI? We've run into basically the same issue with the emacs interface. We've been avoiding using the json output precisely because the emacs JSON parsing would need to see all the output before it could start parsing. And that wouldn't give us the responsive user interface that we want. One idea I've had for this is to change the output (perhaps with a command-line option) to avoid emitting the outer array. That is, the results would instead be a series of independent JSON objects rather than a single JSON object. That should let the application treat things quickly by simply calling the JSON parser for each complete object. (Though, here, the application would likely want a cheap way to know when the input represented a complete object.) If anyone wants to help improve our JSON output here, then that would be great. For any change to the structure of the JSON output, I'd also like to see some documentation added to specify that structure clearly. =2DCarl =2D-=20 carl.d.worth@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFNQymo6JDdNq8qSWgRAsk/AJ9lEGyf/Gzzwc90+J6CGgxuXGWQTgCfYR8Z M/ZC0NrBeU2AIvakTZ1vhYc= =pCZi -----END PGP SIGNATURE----- --=-=-=--