49/fd5e6eabd38fe423086d93e87f4112fae13bb8

   1 Return-Path: <dme@dme.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 4EE3F431E62\r
   6         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 00:49:08 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id oRVV27Pv-4sw for <notmuch@notmuchmail.org>;\r
  16         Mon, 16 Jan 2012 00:49:07 -0800 (PST)\r
  17 Received: from mail-we0-f181.google.com (mail-we0-f181.google.com\r
  18         [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id B33C2431FC0\r
  21         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 00:49:07 -0800 (PST)\r
  22 Received: by werh12 with SMTP id h12so1208365wer.26\r
  23         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 00:49:06 -0800 (PST)\r
  24 Received: by 10.216.138.38 with SMTP id z38mr3234994wei.14.1326703746580;\r
  25         Mon, 16 Jan 2012 00:49:06 -0800 (PST)\r
  26 Received: from hotblack-desiato.hh.sledj.net\r
  27         (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25])\r
  28         by mx.google.com with ESMTPS id gf8sm21370268wbb.11.2012.01.16.00.49.04\r
  29         (version=TLSv1/SSLv3 cipher=OTHER);\r
  30         Mon, 16 Jan 2012 00:49:05 -0800 (PST)\r
  31 Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000)\r
  32         id 5DDF39FD88; Mon, 16 Jan 2012 08:49:03 +0000 (GMT)\r
  33 To: Austin Clements <amdragon@MIT.EDU>, Pieter Praet <pieter@praet.org>\r
  34 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
  35         format.\r
  36 In-Reply-To: <87boq4q23z.fsf@awakening.csail.mit.edu>\r
  37 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
  38         <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>\r
  39         <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>\r
  40         <87ipmewo4z.fsf@servo.finestructure.net>\r
  41         <20111123034021.GL9351@mit.edu> <87ipkglui4.fsf@praet.org>\r
  42         <20120112172840.GC18625@mit.edu> <87ehv2proa.fsf@praet.org>\r
  43         <cun1ur16v3r.fsf@hotblack-desiato.hh.sledj.net>\r
  44         <87boq4q23z.fsf@awakening.csail.mit.edu>\r
  45 User-Agent: Notmuch/0.10.2+186~gd0f7804 (http://notmuchmail.org)\r
  46         Emacs/24.0.92.1 (x86_64-pc-linux-gnu)\r
  47 From: David Edmondson <dme@dme.org>\r
  48 Date: Mon, 16 Jan 2012 08:49:03 +0000\r
  49 Message-ID: <cunlip858xs.fsf@hotblack-desiato.hh.sledj.net>\r
  50 MIME-Version: 1.0\r
  51 Content-Type: multipart/signed; boundary="=-=-=";\r
  52         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  53 Cc: notmuch@notmuchmail.org\r
  54 X-BeenThere: notmuch@notmuchmail.org\r
  55 X-Mailman-Version: 2.1.13\r
  56 Precedence: list\r
  57 List-Id: "Use and development of the notmuch mail system."\r
  58         <notmuch.notmuchmail.org>\r
  59 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  60         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  61 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  62 List-Post: <mailto:notmuch@notmuchmail.org>\r
  63 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  64 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  66 X-List-Received-Date: Mon, 16 Jan 2012 08:49:08 -0000\r
  67 \r
  68 --=-=-=\r
  69 Content-Type: text/plain\r
  70 \r
  71 On Sun, 15 Jan 2012 12:58:40 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
  72 > Yes.  I was mostly reiterating the IRC discussion for Pieter.  Since\r
  73 > this discussion, I've stabilized on the pre-fetching notion I described\r
  74 > in id:"20120115003617.GH1801@mit.edu",\r
  75 \r
  76 Will read when I get there.\r
  77 \r
  78 > though I do think we should make this clear in the code: that the rule\r
  79 > for whether the JSON includes a "content" key for a leaf part is\r
  80 > internal to the CLI and that consumers should be prepared to use it if\r
  81 > it's there and to retrieve the content separately if it's not.  This\r
  82 > is exactly how the Emacs code happens to work, it just hasn't been\r
  83 > codified anywhere.\r
  84 \r
  85 It's a bit more than 'happens to work' :-)\r
  86 \r
  87 > Looking at it this way gives us more flexibility than the current code\r
  88 > takes advantage of; for example we could omit content from the JSON if\r
  89 > it's over some size threshold since the cost of sending that to a\r
  90 > client that doesn't need it is high while the cost of having the\r
  91 > client retrieve it for itself is relatively low.\r
  92 \r
  93 This, I suspect, brings us back to what may have been Dmitry's original\r
  94 concern. If we codify the current behaviour then we're actually\r
  95 _forcing_ clients to use inline content if it's present, because\r
  96 otherwise they have no way to discover the charset/encoding used for the\r
  97 raw part.\r
  98 \r
  99 That seems as though it could be a problem for some clients.\r
 100 \r
 101 > OTOH, I don't understand the encoding story for HTML, since the encoding\r
 102 > can come from either a header or from the body of the HTML.  Does this\r
 103 > make it strictly necessary for the client to handle the encoding?\r
 104 \r
 105 If it can be specified by the content of a part rather than the part\r
 106 headers, then I think that the client will have to be prepared to handle\r
 107 it.\r
 108 \r
 109 Even if not, it might still be more effective to choose that approach -\r
 110 it would remove the need to add arbitrary encoding support to the CLI\r
 111 application.\r
 112 \r
 113 --=-=-=\r
 114 Content-Type: application/pgp-signature\r
 115 \r
 116 -----BEGIN PGP SIGNATURE-----\r
 117 Version: GnuPG v1.4.11 (GNU/Linux)\r
 118 \r
 119 iEYEARECAAYFAk8T5H8ACgkQaezQq/BJZRbX1QCgjcH8RA7k18AuX1KCrOLqu1f1\r
 120 NcEAn1D/XyIL6lUFNQH0V3t6MDzSn07D\r
 121 =3UTq\r
 122 -----END PGP SIGNATURE-----\r
 123 --=-=-=--\r