e5/a363a3e1ec4f53c952ede2d8b340fb80c23afc

   1 Return-Path: <tomi.valkeinen@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 D4CA1431FD4\r
   6         for <notmuch@notmuchmail.org>; Mon, 18 Nov 2013 06:46:23 -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.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         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 Z9HnpNDogKgD for <notmuch@notmuchmail.org>;\r
  17         Mon, 18 Nov 2013 06:46:14 -0800 (PST)\r
  18 Received: from mail-la0-f47.google.com (mail-la0-f47.google.com\r
  19         [209.85.215.47]) (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 1EBD0431FBF\r
  22         for <notmuch@notmuchmail.org>; Mon, 18 Nov 2013 06:46:12 -0800 (PST)\r
  23 Received: by mail-la0-f47.google.com with SMTP id ep20so4936732lab.34\r
  24         for <notmuch@notmuchmail.org>; Mon, 18 Nov 2013 06:46:11 -0800 (PST)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
  26         h=sender:message-id:date:from:user-agent:mime-version:to:subject\r
  27         :content-type; bh=SeiOMcvjodu43hbCVwySpueCMqz0Vn5dL31JmgCKKOU=;\r
  28         b=NdtaWyZlGOUCgVp965EzFq072DVOHClNqKmsQ59z7kBoO3pzna6zaVOcgtI0eEYLmO\r
  29         v0VWFA9dJNv1YVhtMzI1q1pbRhLoFT5PavBAIBuvQB4k9VYO5wAkNlXkG+IKTi6Hh/Bw\r
  30         AFI+qsCYyb6vQQYKydZIDTZkhMrmF+K1tCuGp4xnVuXmmMkxHpQ5ilgPAewQ+UoH/+93\r
  31         2UCqV/kw3oPPa4Jy62p7DiMtcAPYbxWKV/s5jwqZOhzZz++y/w50UH9Q6ccUf1nxYRy1\r
  32         3GgIBVDEy4jw58YwXpM7665Yul0MyAtrk3zyHOv08EOfzO0o0EKclL3eUJplTcAqLPMx\r
  33         Hmkw==\r
  34 X-Received: by 10.112.136.163 with SMTP id qb3mr13852875lbb.14.1384785655593; \r
  35         Mon, 18 Nov 2013 06:40:55 -0800 (PST)\r
  36 Received: from [192.168.1.3] (a91-156-160-115.elisa-laajakaista.fi.\r
  37         [91.156.160.115])\r
  38         by mx.google.com with ESMTPSA id vx8sm12543355lbb.8.2013.11.18.06.40.53\r
  39         for <notmuch@notmuchmail.org>\r
  40         (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);\r
  41         Mon, 18 Nov 2013 06:40:54 -0800 (PST)\r
  42 Sender: Tomi Valkeinen <tomi.valkeinen@gmail.com>\r
  43 Message-ID: <528A26F4.3040006@iki.fi>\r
  44 Date: Mon, 18 Nov 2013 16:40:52 +0200\r
  45 From: Tomi Valkeinen <tomi.valkeinen@iki.fi>\r
  46 User-Agent: Mozilla/5.0 (X11; Linux x86_64;\r
  47         rv:24.0) Gecko/20100101 Thunderbird/24.1.0\r
  48 MIME-Version: 1.0\r
  49 To: notmuch@notmuchmail.org\r
  50 Subject: notmuch-lib questions and observations\r
  51 X-Enigmail-Version: 1.6\r
  52 Content-Type: multipart/signed; micalg=pgp-sha1;\r
  53         protocol="application/pgp-signature";\r
  54         boundary="wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC"\r
  55 X-BeenThere: notmuch@notmuchmail.org\r
  56 X-Mailman-Version: 2.1.13\r
  57 Precedence: list\r
  58 List-Id: "Use and development of the notmuch mail system."\r
  59         <notmuch.notmuchmail.org>\r
  60 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  62 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  63 List-Post: <mailto:notmuch@notmuchmail.org>\r
  64 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  65 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  67 X-List-Received-Date: Mon, 18 Nov 2013 14:46:24 -0000\r
  68 \r
  69 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)\r
  70 --wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC\r
  71 Content-Type: text/plain; charset=ISO-8859-1\r
  72 Content-Transfer-Encoding: quoted-printable\r
  73 \r
  74 Hi,\r
  75 \r
  76 I found out about notmuch quite recently, and now I've been tinkering\r
  77 with it, prototyping a GUI client. I have some questions and observations=\r
  78 :\r
  79 \r
  80 1.\r
  81 \r
  82 The API seems to be a bit broken. I think many of the functions should\r
  83 return notmuch_status_t. I encountered this issue with get_header() and\r
  84 get_date(), which I happened to call after the DB had been changed\r
  85 twice, leading to Xapian::DatabaseModifiedError.\r
  86 \r
  87 Neither function handle the exception, causing a crash, which is\r
  88 obviously a bug, but even if they did handle the exception they don't\r
  89 return any sensible error information. Even worse, consider\r
  90 count_messages(), for which return value of 0 is valid.\r
  91 \r
  92 So, as far as I see, many of the funcs should be changed to something lik=\r
  93 e:\r
  94 \r
  95 notmuch_status_t\r
  96 notmuch_query_count_messages (notmuch_query_t *query, unsigned *count);\r
  97 \r
  98 \r
  99 2.\r
 100 \r
 101 This is more about Xapian, I guess. The behavior that a db reader will\r
 102 start failing if the db has been changed twice is rather bad. If I'm not\r
 103 mistaken, having a rather long read-only query could be blocked (or,\r
 104 well, re-tried) forever, if there just happens to be a few db writes\r
 105 during the read.\r
 106 \r
 107 I think a better approach would be to allow only one change to the db if\r
 108 there are open db readers. If a second db writer tries to open the db,\r
 109 it would get a failure (instead of the readers).\r
 110 \r
 111 Anyone know if this has been discussed, or if my suggestion is plain sill=\r
 112 y?\r
 113 \r
 114 3.\r
 115 \r
 116 How is a client using notmuch supposed to find out there are new\r
 117 messages, and which messages are new?\r
 118 \r
 119 My current thought is to make 'notmuch new' run a script that tags the\r
 120 messages, and make it add a 'new-gui' or such tag to all new messages.\r
 121 The client would then periodically make a query for that tag, and at the\r
 122 same time remove the tag for any returned messages.\r
 123 \r
 124 4.\r
 125 \r
 126 Has there been discussion on returning integer IDs instead of strings\r
 127 from various functions like notmuch_message_get_message_id() and\r
 128 notmuch_tags_get()?\r
 129 \r
 130 I have two things behind this question:\r
 131 \r
 132 - Marshaling strings from native code to managed code requires\r
 133 allocating memory and copying the string, whereas returning an int is\r
 134 more or less a no-op [1][2]. E.g. at the moment if I fetch tag 'inbox'\r
 135 for 10k messages, I'm creating a new 'inbox' string 10k times. I'd\r
 136 rather fetch an int 10k times, and the 'inbox' string once.\r
 137 \r
 138 - My prototype fetches the message ids for all the messages returned by\r
 139 the query, so that it can later load the message if the user wants to\r
 140 read it. Fetching and storing only an int per message versus a long-ish\r
 141 string per message would most likely be good for performance with large\r
 142 queries.\r
 143 \r
 144 5.\r
 145 \r
 146 This one is just a vague thought that came to my mind. At the moment\r
 147 notmuch hides Xapian totally behind notmuch's interface, which probably\r
 148 makes things simpler (and gives a nice C API), but also (afaik) prevents\r
 149 using Xapian features that are not at the moment supported in the\r
 150 notmuch API.\r
 151 \r
 152 I wonder how would an approach work where notmuch would be a bit more\r
 153 like a helper library, allowing full use of Xapian's features but making\r
 154 it simple to manage notmuch database. So, for example, when making a\r
 155 query, you'd create a Xapian query with notmuch, and then use Xapian to\r
 156 run the query.\r
 157 \r
 158 I don't have anything clear in mind, and obviously Xapian being C++\r
 159 might make the whole idea unimplementable.\r
 160 \r
 161  Tomi\r
 162 \r
 163 \r
 164 [1] That's on C#. I wouldn't be surprised if it's also the same with\r
 165 other higher level languages.\r
 166 \r
 167 [2] That's not entirely true, as strings can be passed as is, if the\r
 168 managed code is given the ownership of the string, and the managed code\r
 169 will free the string eventually.\r
 170 \r
 171 \r
 172 --wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC\r
 173 Content-Type: application/pgp-signature; name="signature.asc"\r
 174 Content-Description: OpenPGP digital signature\r
 175 Content-Disposition: attachment; filename="signature.asc"\r
 176 \r
 177 -----BEGIN PGP SIGNATURE-----\r
 178 Version: GnuPG v1.4.14 (GNU/Linux)\r
 179 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/\r
 180 \r
 181 iQIcBAEBAgAGBQJSiib0AAoJEPo9qoy8lh71z68P/3iZg15rtu/7Vwj1VZnZ4OA3\r
 182 sDkbptjc0MNa21YxlCQcDzrhW+Da96wtIC+Vfj0ZMrCSAkuU7qaI7DvhpZk1iQCJ\r
 183 u79/M2klKgEq6YpMZr1HOtUmoAh4FXl5qtZDO3iGtkglGma3bkT7j8c9K24EwMEc\r
 184 6ZILkvplD/nrGHqnx9cXVVCDrAdwVYXUqnO3BFpDiHip+O7iLRYxBXXdJHoblkmd\r
 185 mTcU9Z4J2awH+zL+o/h1Khny7U5JdWbyAMJvmASHlyqa/BCXfYORE2htRQBw0USk\r
 186 qxlGOjWQqEIA7Qrs+KXmq+tbW4Dxdlo11DXPBdHe05E+mSyBkblO7C2lMN+Y9kg0\r
 187 WhmOKqt3AYnjFUpqb9M3Fw5jK76FWp9JYPj6TvsYYgwEDvpsDXqnQIWgRCW8xphT\r
 188 AmKpeL2CpF2pLR5pV6zymWcwyJW8ysYijf8aO/CbLgdlgPYltLnQzxO3jeUplWwF\r
 189 f8gv22IRUwolJOqQ3J1pQ5F+sBTc6ZwNN81wjSEEizrfOT7O0mTl30Wu7OJRYnUX\r
 190 bEfzXlKjopo0bO3CUjsq/wv8GDAsjRv0eYTVUuhGc3zKwo1ZjDoHpqgDY/PNSQnX\r
 191 f+Yshd1+1ModXqup20QSWeVIW86BiNb1MDgDGXsM2wkUyxb7+5FZ+YDO1JBkrllI\r
 192 ZEGw3PCaDzgZ6tcmgpOM\r
 193 =702r\r
 194 -----END PGP SIGNATURE-----\r
 195 \r
 196 --wmE6ev4CTJF6STxfvwCGAG75IKbnj5iTC--\r