To: Austin Clements <amdragon@MIT.EDU>
Subject: Re: The overloading of show (was Re: [PATCH] Output unmodified
	Content-Type header value for JSON format.)
In-Reply-To: <20120115003617.GH1801@mit.edu>
References: <20120115003617.GH1801@mit.edu>
User-Agent: Notmuch/0.11+64~g42e8f66 (http://notmuchmail.org) Emacs/24.0.92.1
	(x86_64-pc-linux-gnu)
From: David Edmondson <dme@dme.org>
Date: Mon, 16 Jan 2012 13:50:43 +0000
Message-ID: <cunaa5nu570.fsf@hotblack-desiato.hh.sledj.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: notmuch <notmuch@notmuchmail.org>
Precedence: list

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 14 Jan 2012 19:36:17 -0500, Austin Clements <amdragon@MIT.EDU> wrot=
e:
> ...there are several levels of structure here:
>=20
> 1. Threads (query results)
> 2. Thread structure
> 3. Message structure (MIME)
> 4. Part content
>=20
> Currently, search returns 1; show --format=3Djson returns 2, 3, and
> sometimes 4 (but sometimes not); and show --format=3Draw returns 4.
> Notably, 1 does not require opening message files (neither does 2),
> which I consider an important distinction between search and show.
>=20
> Some of the discussion has been about putting 4 squarely in the realm
> of show --format=3Draw.  One counterargument (which has grown on me
> since this discussion) is that the part content included in
> --format=3Djson 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:=20
[1]  http://dme.org/data/emacs/notmuch-lkml.el


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8UKzMACgkQaezQq/BJZRbBxACcCg61tuL9eLvxrXrIiWL3OVTb
JP8AnibEvGhy4wRtAZyEZHvaNHgYSJDJ
=GQP7
-----END PGP SIGNATURE-----
--=-=-=--