Date: Tue, 14 Feb 2012 10:21:14 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Mark Walters <markwalters1009@gmail.com>
Subject: Re: [RFC PATCH v3 00/11] notmuch-pick: an emacs threaded message
	view with split-pane
Message-ID: <20120214152114.GQ27039@mit.edu>
References: <1329072579-27340-1-git-send-email-markwalters1009@gmail.com>
	<1329096015-8078-1-git-send-email-markwalters1009@gmail.com>
	<87haytbnun.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87haytbnun.fsf@qmul.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Mark Walters on Feb 14 at 12:28 pm:
> Finally, if notmuch-pick were able to do work asynchronously (as
> notmuch-search does now) then I think all the speed concerns would go
> away. However, I am not sure how to do incremental json parsing.

For JSON search, at least, I think we've concluded that it should put
newlines at strategic places in the JSON output (and never anywhere
else) so that it's easy for a consumer to know when it has a complete
JSON object and hand it to the JSON parser.  E.g.,

[{"thread":"X", timestamp: 42, ...}
,{"thread":"Y", timestamp: 24, ...}
]

This "framed JSON" works really well for the flat output of search.
It's obviously trickier to apply to show's hierarchical output.  But,
perhaps this will inspire you.

(One possibility: we could rework show's output to be non-hierarchical
and use the above framing; that is, it could be a sequence of message
objects that each indicate which earlier message object they're a
reply to, probably restricted to DFS order.)