On Wed, 12 Jan 2011 19:37:21 +0100, Christophe-Marie Duquesne <chm.duque...@gmail.com> 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=25: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. -Carl -- carl.d.wo...@intel.com
pgpG6sRtRfMiH.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch