Quoth Pieter Praet on Jan 12 at 6:07 pm: > On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements <amdra...@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. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
