Date: Thu, 12 Jan 2012 12:28:40 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Pieter Praet <pieter@praet.org>
Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON
	format.
Message-ID: <20120112172840.GC18625@mit.edu>
References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
	<87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>
	<87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>
	<87ipmewo4z.fsf@servo.finestructure.net>
	<20111123034021.GL9351@mit.edu> <87ipkglui4.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ipkglui4.fsf@praet.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Pieter Praet on Jan 12 at  6:07 pm:
> On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> > Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:
> > > The open question seems to be how we handle the content encoding
> > > parameters.  My argument is that those should either be used by notmuch
> > > to properly encode the content for the consumer.  If that's not
> > > possible, then just those parameters needed by the consumer to decode
> > > the content should be output.
> > 
> > If notmuch is going to include part content in the JSON output (which
> > perhaps it shouldn't, as per recent IRC discussions), then it must
> > handle content encodings because JSON must be Unicode and therefore
> > the content strings in the JSON must be Unicode.
> 
> Having missed the IRC discussions: what is the rationale for not
> including (specific types of?) part content in the JSON output ?
> Eg. how about inline attached text/x-patch ?

Technically the IRC discussion was about not including *any* part
content in the JSON output, and always using show --format=raw or
similar to retrieve desired parts.  Currently, notmuch includes part
content in the JSON only for text/*, *except* when it's text/html.  I
assume non-text parts are omitted because binary data is hard to
represent in JSON and text/html is omitted because some people don't
need it.  However, this leads to some peculiar asymmetry in the Emacs
code where sometimes it pulls part content out of the JSON and
sometimes it retrieves it using show --format=raw.  This in turn leads
to asymmetry in content encoding handling, since notmuch handles
content encoding for parts included in the JSON (and there's no good
way around that since JSON is Unicode), but not for parts retrieved as
raw.

The idea discussed on IRC was to remove all part content from the JSON
output and to always use show to retrieve it, possibly beefing up
show's support for content decoding (and possibly introducing a way to
retrieve multiple raw parts at once to avoid re-parsing).  This would
get the JSON format out of the business of guessing what consumers
need, simplify the Emacs code, and normalize content encoding
handling.