Re: Encodings

diff --git a/8a/21d2a44051604b44757c1e27278535f6e28a45 b/8a/21d2a44051604b44757c1e27278535f6e28a45
new file mode 100644 (file)
index 0000000..e2035ae
--- /dev/null
+++ b/8a/21d2a44051604b44757c1e27278535f6e28a45
@@ -0,0 +1,108 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id CC020431FD0\r
+       for <notmuch@notmuchmail.org>; Mon, 11 Jul 2011 08:03:46 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.01\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
+       tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id 5ityJkvnzG5H for <notmuch@notmuchmail.org>;\r
+       Mon, 11 Jul 2011 08:03:46 -0700 (PDT)\r
+Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
+       by olra.theworths.org (Postfix) with ESMTP id 2AD39431FB6\r
+       for <notmuch@notmuchmail.org>; Mon, 11 Jul 2011 08:03:46 -0700 (PDT)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by arlo.cworth.org (Postfix) with ESMTP id BE75B29A551;\r
+       Mon, 11 Jul 2011 08:03:44 -0700 (PDT)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id ABF35254147; Mon, 11 Jul 2011 08:03:44 -0700 (PDT)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Sebastian Spaeth <Sebastian@SSpaeth.de>,\r
+       Notmuch developer list <notmuch@notmuchmail.org>\r
+Subject: Re: Encodings\r
+In-Reply-To: <87zkkkx6am.fsf@SSpaeth.de>\r
+References: <87zkkkx6am.fsf@SSpaeth.de>\r
+User-Agent: Notmuch/0.6 (http://notmuchmail.org) Emacs/23.3.1\r
+       (i486-pc-linux-gnu)\r
+Date: Mon, 11 Jul 2011 08:03:38 -0700\r
+Message-ID: <87box0lv05.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 11 Jul 2011 15:03:46 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth <Sebastian@SSpaeth.de>=\r
+ wrote:\r
+> The answer is that things are very implicit. notmuch.h speaks of\r
+> strings but never mentions encodings\r
+\r
+Much of this was intentional on my part.\r
+\r
+For example, I intentionally avoided restrictions on what could be\r
+stored as a tag in the database, (other than the terminating character\r
+implied by "string" of course).\r
+\r
+> So, can be document what encoding we are expected to pass in the various\r
+> APIs\r
+\r
+Yes, let's clarify documentation wherever we need to.\r
+\r
+> For some of the stuff we read directly from the files, eg\r
+> arbitrary headers, we can probably be least sure\r
+\r
+The headers should be decoded to utf-8, (via\r
+g_mime_utils_header_decode_text), before being stored in the database.\r
+\r
+> but are e.g. the returned tags always utf-8?\r
+\r
+No. The tag data is returned exactly as the user presented it.\r
+\r
+> I would love to make the python bindings use unicode() instances in\r
+> cases where we can be sure to actually receive utf-8 encoded strings.\r
+>=20\r
+> Encodings make my brain hurt. Unfortunately one cannot simply ignore\r
+> them.\r
+\r
+I think a lot of the pain here is due to some bad design decisions in\r
+python itself. Of course, my saying that doesn't make things any easier\r
+for you.\r
+\r
+But do tell me what more we can do to clarify behavior or documentation.\r
+\r
+=2DCarl\r
+\r
+=2D-=20\r
+carl.d.worth@intel.com\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk4bEMoACgkQ6JDdNq8qSWg8oACeKTnWC2O8P95anL+EL8oKpHuL\r
+qxAAoJMTieU15udi6b2wvSSszOKfnex5\r
+=a4mc\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r