On Sat, 14 Jan 2012 19:36:17 -0500, Austin Clements <amdragon@MIT.EDU> wrote: > ...there are several levels of structure here: > > 1. Threads (query results) > 2. Thread structure > 3. Message structure (MIME) > 4. Part content > > Currently, search returns 1; show --format=json returns 2, 3, and > sometimes 4 (but sometimes not); and show --format=raw returns 4. > Notably, 1 does not require opening message files (neither does 2), > which I consider an important distinction between search and show. > > Some of the discussion has been about putting 4 squarely in the realm > of show --format=raw. One counterargument (which has grown on me > since this discussion) is that the part content included in > --format=json can be thought of as pre-fetching content that clients > are likely to need in order to avoid re-parsing the message in most > circumstances. I believe this is not the *intent* of the current > code, though without a specification of the JSON format it's hard to > tell. The JSON output included what was considered useful (mostly for the Emacs UI), but how much deep thought went into 'useful' I couldn't say. > Other discussion (more interesting, in my mind) has been about > separating retrieving thread structure, 2, from retrieving message > structure, 3. To me, splitting these feels much more natural than > what we do now, which seems to be inflexibly bound to the specific way > the Emacs show mode currently works. The thread structure is readily > available from the database, so I think separating these would open up > some new UI opportunities, particularly easy and fast thread outlining > and navigation. Given that the current output already includes both 2 and 3, anything that could be done with 2 can be done with the current output, so there's no block on the kind of innovation that you describe other than possibly some performance problems. notmuch-lkml.el[1] was a quick prototype of an alternative way to find messages to read based on suggestions from Aneesh. It could have used the proposed 'thread structure only' output. The changes you allude to make sense. My only concern would be any potential impact on the current Emacs UI's use of JSON output. Switching to a model where a typical 'notmuch-show' buffer requires many calls to notmuch (and commensurate JSON parsing) may perform significantly worse than the current approach. > I believe it would also simplify the code and address some irritating > asymmetries in the way notmuch show handles the --part argument. Footnotes: [1] http://dme.org/data/emacs/notmuch-lkml.el