--- /dev/null
+Return-Path: <tomi.valkeinen@gmail.com>\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 D4CA1431FD4\r
+ for <notmuch@notmuchmail.org>; Mon, 18 Nov 2013 06:46:23 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.699\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
+ RCVD_IN_DNSWL_LOW=-0.7] 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 Z9HnpNDogKgD for <notmuch@notmuchmail.org>;\r
+ Mon, 18 Nov 2013 06:46:14 -0800 (PST)\r
+Received: from mail-la0-f47.google.com (mail-la0-f47.google.com\r
+ [209.85.215.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 1EBD0431FBF\r
+ for <notmuch@notmuchmail.org>; Mon, 18 Nov 2013 06:46:12 -0800 (PST)\r
+Received: by mail-la0-f47.google.com with SMTP id ep20so4936732lab.34\r
+ for <notmuch@notmuchmail.org>; Mon, 18 Nov 2013 06:46:11 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+ h=sender:message-id:date:from:user-agent:mime-version:to:subject\r
+ :content-type; bh=SeiOMcvjodu43hbCVwySpueCMqz0Vn5dL31JmgCKKOU=;\r
+ b=NdtaWyZlGOUCgVp965EzFq072DVOHClNqKmsQ59z7kBoO3pzna6zaVOcgtI0eEYLmO\r
+ v0VWFA9dJNv1YVhtMzI1q1pbRhLoFT5PavBAIBuvQB4k9VYO5wAkNlXkG+IKTi6Hh/Bw\r
+ AFI+qsCYyb6vQQYKydZIDTZkhMrmF+K1tCuGp4xnVuXmmMkxHpQ5ilgPAewQ+UoH/+93\r
+ 2UCqV/kw3oPPa4Jy62p7DiMtcAPYbxWKV/s5jwqZOhzZz++y/w50UH9Q6ccUf1nxYRy1\r
+ 3GgIBVDEy4jw58YwXpM7665Yul0MyAtrk3zyHOv08EOfzO0o0EKclL3eUJplTcAqLPMx\r
+ Hmkw==\r
+X-Received: by 10.112.136.163 with SMTP id qb3mr13852875lbb.14.1384785655593; \r
+ Mon, 18 Nov 2013 06:40:55 -0800 (PST)\r
+Received: from [192.168.1.3] (a91-156-160-115.elisa-laajakaista.fi.\r
+ [91.156.160.115])\r
+ by mx.google.com with ESMTPSA id vx8sm12543355lbb.8.2013.11.18.06.40.53\r
+ for <notmuch@notmuchmail.org>\r
+ (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);\r
+ Mon, 18 Nov 2013 06:40:54 -0800 (PST)\r
+Sender: Tomi Valkeinen <tomi.valkeinen@gmail.com>\r
+Message-ID: <528A26F4.3040006@iki.fi>\r
+Date: Mon, 18 Nov 2013 16:40:52 +0200\r
+From: Tomi Valkeinen <tomi.valkeinen@iki.fi>\r
+User-Agent: Mozilla/5.0 (X11; Linux x86_64;\r
+ rv:24.0) Gecko/20100101 Thunderbird/24.1.0\r
+MIME-Version: 1.0\r
+To: notmuch@notmuchmail.org\r
+Subject: notmuch-lib questions and observations\r
+X-Enigmail-Version: 1.6\r
+Content-Type: multipart/signed; micalg=pgp-sha1;\r
+ protocol="application/pgp-signature";\r
+ boundary="wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC"\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, 18 Nov 2013 14:46:24 -0000\r
+\r
+This is an OpenPGP/MIME signed message (RFC 4880 and 3156)\r
+--wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC\r
+Content-Type: text/plain; charset=ISO-8859-1\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Hi,\r
+\r
+I found out about notmuch quite recently, and now I've been tinkering\r
+with it, prototyping a GUI client. I have some questions and observations=\r
+:\r
+\r
+1.\r
+\r
+The API seems to be a bit broken. I think many of the functions should\r
+return notmuch_status_t. I encountered this issue with get_header() and\r
+get_date(), which I happened to call after the DB had been changed\r
+twice, leading to Xapian::DatabaseModifiedError.\r
+\r
+Neither function handle the exception, causing a crash, which is\r
+obviously a bug, but even if they did handle the exception they don't\r
+return any sensible error information. Even worse, consider\r
+count_messages(), for which return value of 0 is valid.\r
+\r
+So, as far as I see, many of the funcs should be changed to something lik=\r
+e:\r
+\r
+notmuch_status_t\r
+notmuch_query_count_messages (notmuch_query_t *query, unsigned *count);\r
+\r
+\r
+2.\r
+\r
+This is more about Xapian, I guess. The behavior that a db reader will\r
+start failing if the db has been changed twice is rather bad. If I'm not\r
+mistaken, having a rather long read-only query could be blocked (or,\r
+well, re-tried) forever, if there just happens to be a few db writes\r
+during the read.\r
+\r
+I think a better approach would be to allow only one change to the db if\r
+there are open db readers. If a second db writer tries to open the db,\r
+it would get a failure (instead of the readers).\r
+\r
+Anyone know if this has been discussed, or if my suggestion is plain sill=\r
+y?\r
+\r
+3.\r
+\r
+How is a client using notmuch supposed to find out there are new\r
+messages, and which messages are new?\r
+\r
+My current thought is to make 'notmuch new' run a script that tags the\r
+messages, and make it add a 'new-gui' or such tag to all new messages.\r
+The client would then periodically make a query for that tag, and at the\r
+same time remove the tag for any returned messages.\r
+\r
+4.\r
+\r
+Has there been discussion on returning integer IDs instead of strings\r
+from various functions like notmuch_message_get_message_id() and\r
+notmuch_tags_get()?\r
+\r
+I have two things behind this question:\r
+\r
+- Marshaling strings from native code to managed code requires\r
+allocating memory and copying the string, whereas returning an int is\r
+more or less a no-op [1][2]. E.g. at the moment if I fetch tag 'inbox'\r
+for 10k messages, I'm creating a new 'inbox' string 10k times. I'd\r
+rather fetch an int 10k times, and the 'inbox' string once.\r
+\r
+- My prototype fetches the message ids for all the messages returned by\r
+the query, so that it can later load the message if the user wants to\r
+read it. Fetching and storing only an int per message versus a long-ish\r
+string per message would most likely be good for performance with large\r
+queries.\r
+\r
+5.\r
+\r
+This one is just a vague thought that came to my mind. At the moment\r
+notmuch hides Xapian totally behind notmuch's interface, which probably\r
+makes things simpler (and gives a nice C API), but also (afaik) prevents\r
+using Xapian features that are not at the moment supported in the\r
+notmuch API.\r
+\r
+I wonder how would an approach work where notmuch would be a bit more\r
+like a helper library, allowing full use of Xapian's features but making\r
+it simple to manage notmuch database. So, for example, when making a\r
+query, you'd create a Xapian query with notmuch, and then use Xapian to\r
+run the query.\r
+\r
+I don't have anything clear in mind, and obviously Xapian being C++\r
+might make the whole idea unimplementable.\r
+\r
+ Tomi\r
+\r
+\r
+[1] That's on C#. I wouldn't be surprised if it's also the same with\r
+other higher level languages.\r
+\r
+[2] That's not entirely true, as strings can be passed as is, if the\r
+managed code is given the ownership of the string, and the managed code\r
+will free the string eventually.\r
+\r
+\r
+--wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+Content-Description: OpenPGP digital signature\r
+Content-Disposition: attachment; filename="signature.asc"\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.14 (GNU/Linux)\r
+Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/\r
+\r
+iQIcBAEBAgAGBQJSiib0AAoJEPo9qoy8lh71z68P/3iZg15rtu/7Vwj1VZnZ4OA3\r
+sDkbptjc0MNa21YxlCQcDzrhW+Da96wtIC+Vfj0ZMrCSAkuU7qaI7DvhpZk1iQCJ\r
+u79/M2klKgEq6YpMZr1HOtUmoAh4FXl5qtZDO3iGtkglGma3bkT7j8c9K24EwMEc\r
+6ZILkvplD/nrGHqnx9cXVVCDrAdwVYXUqnO3BFpDiHip+O7iLRYxBXXdJHoblkmd\r
+mTcU9Z4J2awH+zL+o/h1Khny7U5JdWbyAMJvmASHlyqa/BCXfYORE2htRQBw0USk\r
+qxlGOjWQqEIA7Qrs+KXmq+tbW4Dxdlo11DXPBdHe05E+mSyBkblO7C2lMN+Y9kg0\r
+WhmOKqt3AYnjFUpqb9M3Fw5jK76FWp9JYPj6TvsYYgwEDvpsDXqnQIWgRCW8xphT\r
+AmKpeL2CpF2pLR5pV6zymWcwyJW8ysYijf8aO/CbLgdlgPYltLnQzxO3jeUplWwF\r
+f8gv22IRUwolJOqQ3J1pQ5F+sBTc6ZwNN81wjSEEizrfOT7O0mTl30Wu7OJRYnUX\r
+bEfzXlKjopo0bO3CUjsq/wv8GDAsjRv0eYTVUuhGc3zKwo1ZjDoHpqgDY/PNSQnX\r
+f+Yshd1+1ModXqup20QSWeVIW86BiNb1MDgDGXsM2wkUyxb7+5FZ+YDO1JBkrllI\r
+ZEGw3PCaDzgZ6tcmgpOM\r
+=702r\r
+-----END PGP SIGNATURE-----\r
+\r
+--wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC--\r