Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email
[notmuch-archives.git] / 76 / 6aca3655c0ad020d2adb0ab79cfd7280d4af54
1 Return-Path: <dmitry.kurochkin@gmail.com>\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 DFA61429E25\r
6         for <notmuch@notmuchmail.org>; Fri, 18 Nov 2011 18:42:20 -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.799\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id jy1rJ0mKhZsC for <notmuch@notmuchmail.org>;\r
17         Fri, 18 Nov 2011 18:42:20 -0800 (PST)\r
18 Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com\r
19         [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id 19FF3431FD0\r
22         for <notmuch@notmuchmail.org>; Fri, 18 Nov 2011 18:42:19 -0800 (PST)\r
23 Received: by bkaq10 with SMTP id q10so4539876bka.26\r
24         for <notmuch@notmuchmail.org>; Fri, 18 Nov 2011 18:42:17 -0800 (PST)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
26         h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
27         :mime-version:content-type;\r
28         bh=5L1h2QwZC+WafHLf07fw9weYcE2GrtPeTqBOIYcakzw=;\r
29         b=Rb6E0SPolrjX1+1unJsIep5C2kIadUB0InkqspkKLdVGro9B+A6iIEP3Z30AhQk1uS\r
30         yYsdA4FDYU4J93epO6XqkMrgLuPtwOs8R/fJECh3Fwto/Cp1zwkOssiy7seVJ7r6wFGB\r
31         OoEbA8wyueEfvT/4k//kWXe2Y3o1jGdPoXTmQ=\r
32 Received: by 10.205.121.1 with SMTP id ga1mr3270666bkc.60.1321670537203;\r
33         Fri, 18 Nov 2011 18:42:17 -0800 (PST)\r
34 Received: from localhost ([91.144.186.21])\r
35         by mx.google.com with ESMTPS id e8sm2095532bkd.7.2011.11.18.18.42.15\r
36         (version=TLSv1/SSLv3 cipher=OTHER);\r
37         Fri, 18 Nov 2011 18:42:16 -0800 (PST)\r
38 From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>\r
39 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
40  notmuch@notmuchmail.org\r
41 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
42         format.\r
43 In-Reply-To: <87fwhkyisj.fsf@servo.finestructure.net>\r
44 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
45         <87fwhkyisj.fsf@servo.finestructure.net>\r
46 User-Agent: Notmuch/0.10~rc1+20~gec94ced (http://notmuchmail.org) Emacs/23.3.1\r
47         (x86_64-pc-linux-gnu)\r
48 Date: Sat, 19 Nov 2011 06:42:00 +0400\r
49 Message-ID: <87wrawq1dz.fsf@gmail.com>\r
50 MIME-Version: 1.0\r
51 Content-Type: text/plain; charset=us-ascii\r
52 X-BeenThere: notmuch@notmuchmail.org\r
53 X-Mailman-Version: 2.1.13\r
54 Precedence: list\r
55 List-Id: "Use and development of the notmuch mail system."\r
56         <notmuch.notmuchmail.org>\r
57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
60 List-Post: <mailto:notmuch@notmuchmail.org>\r
61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
64 X-List-Received-Date: Sat, 19 Nov 2011 02:42:21 -0000\r
65 \r
66 Hi Jamie.\r
67 \r
68 On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
69 > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:\r
70 > > Before the change, notmuch used g_mime_content_type_to_string(3)\r
71 > > function to output Content-Type header value.  Turns out it outputs\r
72 > > only "type/subtype" part and ignores all parameters.  Also, if there\r
73 > > is no Content-Type header, default "text/plain" value is used.\r
74\r
75 > Hi, Dmitry.  Can you explain under what circumstances you would need the\r
76 > extra content-type parameters?\r
77 \r
78 Charset is an example of a parameter which you need to render a part\r
79 correctly.\r
80 \r
81 >  It just seems like a lot of extra noise\r
82 > in the output to me, but that's partially because I can't think of any\r
83 > reason why something that is receiving pre-parsed mime content would\r
84 > need it.  Maybe there's a better way to handle what you're trying to get\r
85 > to.\r
86\r
87 \r
88 Why extra output in JSON is an issue?\r
89 \r
90 The parameters are there for a reason.  They are part of the\r
91 content-type and are needed to handle the body properly.  If you say\r
92 that the parameters are not needed by notmuch users, that implies that\r
93 they are handled by notmuch.  Which is just not possible.\r
94 \r
95 > I think it would help a lot if you could submit some sort of test\r
96 > modification that demonstrates the issue.  This is one of the reasons we\r
97 > keep emphasizing that it's good to first have tests in hand that\r
98 > demonstrate issues before patches that address them.\r
99\r
100 \r
101 The fact that this change happens to fix an issue with HTML charsets for\r
102 me is just a side effect.\r
103 \r
104 The real issue is that JSON format throws away information which is\r
105 required to properly render a part.  I do not think we need to add a\r
106 dedicated test to check that JSON outputs charsets with parameters,\r
107 considering that it is already present in many other tests.\r
108 \r
109 I do not think it was intended that notmuch outputs stripped\r
110 Content-Type values.  It was just a side effect of using\r
111 g_mime_content_type_to_string(3) which gone unnoticed.\r
112 \r
113 > >   "content": [{"id": 2,\r
114 > > - "content-type": "text/plain",\r
115 > >   "content": "This is a test signed message.\n"},\r
116\r
117 > Without figuring out what's going on, I notice that some of the tests\r
118 > have been modified to remove the content-type fields on a bunch of\r
119 > parts.  I think that is probably not right.\r
120\r
121 \r
122 I tried to explain this in the preable.  These parts do not have\r
123 Content-Type in the original message.  So I think it is wrong for\r
124 notmuch JSON format to add it.\r
125 \r
126 Regards,\r
127   Dmitry\r
128 \r
129 > jamie.\r