From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id A672C429E36 for ; Thu, 12 Jan 2012 09:28:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5ymqneYazP4 for ; Thu, 12 Jan 2012 09:28:40 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by olra.theworths.org (Postfix) with ESMTP id D1F58431FB6 for ; Thu, 12 Jan 2012 09:28:39 -0800 (PST) X-AuditID: 1209190c-b7fad6d000000920-94-4f0f18479d6f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.1D.02336.7481F0F4; Thu, 12 Jan 2012 12:28:39 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q0CHSceN001908; Thu, 12 Jan 2012 12:28:39 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0CHSb3v009914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 12 Jan 2012 12:28:38 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RlOS8-0006F8-Py; Thu, 12 Jan 2012 12:28:40 -0500 Date: Thu, 12 Jan 2012 12:28:40 -0500 From: Austin Clements To: Pieter Praet 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) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixCmqrOsuwe9vsPKFlMWefV4W12/OZLb4 /foGswOzx93TXB7PVt1i9ujYd5k1gDmKyyYlNSezLLVI3y6BK+PEmxNsBUcEK87s38HewNjD 18XIySEhYCIx6ekTJghbTOLCvfVsXYxcHEIC+xglfk6ewQ7hbGCUaJjezwThnGSSWLb6HwuE s4RR4sXhFcxdjBwcLAKqEi3LqkBGsQloSGzbv5wRxBYRUJY4/eQnO4jNLBAhMWXGR7B1wgLB Ei+XtYPZvAI6EgfmHmMFsYUEjjBJXJhZDBEXlDg58wkLRK+WxI1/L5lAVjELSEss/8cBEuYU UJd4tGwJWKuogIrElJPb2CYwCs1C0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKL dA31cjNL9FJTSjcxgsNckmcH45uDSocYBTgYlXh4Xwnz+wuxJpYVV+YeYpTkYFIS5c0XAwrx JeWnVGYkFmfEF5XmpBYfYpTgYFYS4Z18ns9fiDclsbIqtSgfJiXNwaIkzqui9c5PSCA9sSQ1 OzW1ILUIJivDwaEkwTtPHGioYFFqempFWmZOCUKaiYMTZDgP0PCjIDW8xQWJucWZ6RD5U4y6 HCfXXjnHKMSSl5+XKiXOuxekSACkKKM0D24OLD29YhQHekuYdw5IFQ8wtcFNegW0hAloSVkK yAfFJYkIKakGxvpDU7dMFfxxSVJo/U4/tVWvn8YGbfWovFjv0W6aXTG5K2b2kq+uky+5Pt5R fMLiu5TrwuUZh1wfNyhG2OU+ur2zZMGSvgeip3WtUmTsl21P/LCSyaeiXHntau8Ak+9L7O4f kdLqffuowmhuoWWUfH/xCo21Xy48fBr562oC2523LK8O5xq9eKPEUpyRaKjFXFScCACbddDL KgMAAA== Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:28:40 -0000 Quoth Pieter Praet on Jan 12 at 6:07 pm: > On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements 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.