--- /dev/null
+Return-Path: <jani@nikula.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 4660C431FC2\r
+ for <notmuch@notmuchmail.org>; Tue, 19 Nov 2013 04:12:50 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[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 MzNMZqZbyuQe for <notmuch@notmuchmail.org>;\r
+ Tue, 19 Nov 2013 04:12:40 -0800 (PST)\r
+Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com\r
+ [209.85.214.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 5CB41431FBC\r
+ for <notmuch@notmuchmail.org>; Tue, 19 Nov 2013 04:12:40 -0800 (PST)\r
+Received: by mail-bk0-f41.google.com with SMTP id v15so3003256bkz.14\r
+ for <notmuch@notmuchmail.org>; Tue, 19 Nov 2013 04:12:36 -0800 (PST)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:from:to:cc:subject:in-reply-to:references\r
+ :user-agent:date:message-id:mime-version:content-type;\r
+ bh=0qUgGz0G6puhkxonkKzKyT4mZVqLBK4wf/8J5ZEPH6c=;\r
+ b=lidiQgq4cj0k/hGtKrA5yP7I4vgzlxzNBCUgrq8Fu2rklE1O/bGcSnBWobEv4bSvAC\r
+ oKzYh2RFBXPYeF2dHfgkGoJo4vxrEStJY9A9tz86pJ+truTH35VFofaq+h+JntfgSl1Y\r
+ S99YuVL2mh1jZYJBu3aXH6DZi3NOaICVYMV5ZGE44K0NQWbIStz/Z/AdWukvjckcSvw3\r
+ BjBhTQMvGevNRDPa8vcsQzV17vtO0pdsj9NMZHX49bj+Fdt/8ohjK9LvIJqRauHLMIPE\r
+ 4ZwCQOZgxsR49KsielnT1MeECPQVlUhIvv6UcyHnQJmTl+Brd8XZ2oyAMmn6SLYOraLc\r
+ J8tA==\r
+X-Gm-Message-State:\r
+ ALoCoQlix1fv3L7o6n2jN8jJJh/FamkWnarnTgKPgbym2+4F/vnJg3dvuxWUKBs78R7r327pXll7\r
+X-Received: by 10.204.64.78 with SMTP id d14mr5633bki.40.1384863156559;\r
+ Tue, 19 Nov 2013 04:12:36 -0800 (PST)\r
+Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
+ [88.195.111.91])\r
+ by mx.google.com with ESMTPSA id a4sm20247712bko.11.2013.11.19.04.12.34\r
+ for <multiple recipients>\r
+ (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+ Tue, 19 Nov 2013 04:12:35 -0800 (PST)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Tomi Valkeinen <tomi.valkeinen@iki.fi>, notmuch@notmuchmail.org\r
+Subject: Re: notmuch-lib questions and observations\r
+In-Reply-To: <528A26F4.3040006@iki.fi>\r
+References: <528A26F4.3040006@iki.fi>\r
+User-Agent: Notmuch/0.16+145~gebbaa94 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Tue, 19 Nov 2013 14:12:31 +0200\r
+Message-ID: <87bo1gio9c.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\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: Tue, 19 Nov 2013 12:12:50 -0000\r
+\r
+On Mon, 18 Nov 2013, Tomi Valkeinen <tomi.valkeinen@iki.fi> wrote:\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
+Hello Tomi, glad you've found notmuch too! ;)\r
+\r
+Your mail would deserve a more thorough answer that I have time for\r
+right now, but hopefully someone(tm) will fill in.\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
+We should never leak exceptions or do INTERNAL_ERROR() on things that\r
+are not internal errors. So agreed those are bugs.\r
+\r
+> So, as far as I see, many of the funcs should be changed to something like:\r
+>\r
+> notmuch_status_t\r
+> notmuch_query_count_messages (notmuch_query_t *query, unsigned *count);\r
+\r
+We're about to release 0.17, and we expect to have to break the API a\r
+bit after the release anyway. IMO it would be a good time to review this\r
+kind of stuff.\r
+\r
+The bug fixes you sent for not crashing should probably be considered\r
+for 0.17.\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 silly?\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
+'notmuch new' tags any new messages it finds with tags specified in\r
+new.tags config option (man notmuch-config), "inbox" and "unread" by\r
+default. Some people like to change that to "new", and run a post-new\r
+hook (man notmuch-hooks) that looks at messages matching tag:new,\r
+retagging as desired.\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
+As said, 'notmuch new' does that, and it can also run a script for you.\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
+I think the database implementation has been abstracted on purpose, so\r
+we could, at least in theory, switch from xapian to something else. I\r
+don't know how feasible that would be though. I think Austin has\r
+experimented with that.\r
+\r
+\r
+Cheers,\r
+Jani.\r
+\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
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r
projects / notmuch-archives.git / commitdiff