Re: notmuch as a shared object aka library knigge
authorJustus Winter <4winter@informatik.uni-hamburg.de>
Wed, 22 Feb 2012 15:17:45 +0000 (16:17 +0100)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:44:49 +0000 (09:44 -0800)
7f/2d50b86fccaeb22e04f8bf75ba01c8c4f3d564 [new file with mode: 0644]

diff --git a/7f/2d50b86fccaeb22e04f8bf75ba01c8c4f3d564 b/7f/2d50b86fccaeb22e04f8bf75ba01c8c4f3d564
new file mode 100644 (file)
index 0000000..c2ef8c0
--- /dev/null
@@ -0,0 +1,133 @@
+Return-Path: <teythoon@jade-hamburg.de>\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 D30A7431FB6\r
+       for <notmuch@notmuchmail.org>; Wed, 22 Feb 2012 07:17:54 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       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 rWDbHpsuGS1d for <notmuch@notmuchmail.org>;\r
+       Wed, 22 Feb 2012 07:17:54 -0800 (PST)\r
+Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 0F90E431FAE\r
+       for <notmuch@notmuchmail.org>; Wed, 22 Feb 2012 07:17:54 -0800 (PST)\r
+Received: from mail.jade-hamburg.de (unknown [85.183.11.228])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by mail.cryptobitch.de (Postfix) with ESMTPSA id 64D6453133C\r
+       for <notmuch@notmuchmail.org>; Wed, 22 Feb 2012 16:17:51 +0100 (CET)\r
+Received: by mail.jade-hamburg.de (Postfix, from userid 401)\r
+       id D054EDF2A9; Wed, 22 Feb 2012 16:17:50 +0100 (CET)\r
+Received: from thinkbox.jade-hamburg.de (unknown [85.183.11.228])\r
+       (using TLSv1 with cipher AES256-SHA (256/256 bits))\r
+       (No client certificate requested) (Authenticated sender: teythoon)\r
+       by mail.jade-hamburg.de (Postfix) with ESMTPSA id 437FCDF2A5;\r
+       Wed, 22 Feb 2012 16:17:48 +0100 (CET)\r
+Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.77)\r
+       (envelope-from <teythoon@thinkbox.jade-hamburg.de>)\r
+       id 1S0Dwv-0005pH-GE; Wed, 22 Feb 2012 16:17:45 +0100\r
+Content-Type: text/plain; charset="utf-8"\r
+MIME-Version: 1.0\r
+Content-Transfer-Encoding: quoted-printable\r
+To: Austin Clements <amdragon@MIT.EDU>, \r
+From: Justus Winter <4winter@informatik.uni-hamburg.de>\r
+In-Reply-To: <20120221155312.GB30513@mit.edu>\r
+References: <20120221002921.8534.57091@thinkbox.jade-hamburg.de>\r
+       <20120221155312.GB30513@mit.edu>\r
+Message-ID: <20120222151745.4213.93513@thinkbox.jade-hamburg.de>\r
+User-Agent: alot/0.21+\r
+Subject: Re: notmuch as a shared object aka library knigge\r
+Date: Wed, 22 Feb 2012 16:17:45 +0100\r
+Cc: notmuch mailing list <notmuch@notmuchmail.org>\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: Wed, 22 Feb 2012 15:17:55 -0000\r
+\r
+Quoting Austin Clements (2012-02-21 16:53:12)\r
+>Quoth Justus Winter on Feb 21 at  1:29 am:\r
+>> Hi fellow notmuchrs,\r
+>> =\r
+\r
+>> while going through the python bindings I recently came across the\r
+>> following note in the documentation for the Database.get_directory\r
+>> function [0]:\r
+>> =\r
+\r
+>> ~~~ snip ~~~\r
+>> Warning\r
+>> =\r
+\r
+>> This call needs a writable database in Database.MODE.READ_WRITE\r
+>> mode. The underlying library will exit the program if this method is\r
+>> used on a read-only database!\r
+>> ~~~ snap ~~~\r
+>\r
+>This is a bug and should be thought of as such.\r
+\r
+Agreed.\r
+\r
+>INTERNAL_ERROR should\r
+>only be used for internal library inconsistencies (e.g., things that\r
+>should never ever happen) [...]\r
+\r
+Well, I do not agree. If there is a inconsitency within the library\r
+that library should report this to the caller and it is totally okay\r
+to say that if the callee ignores this error, bad things will happen\r
+(i.e. we're in unspecified behavior territory here).\r
+\r
+It is still not okay to kill the whole process. Imagine you're using\r
+the alot mail client that uses libnotmuch through the python bindings\r
+and you've just finished writing a letter when libnotmuch decides to\r
+commit suicide and prevent the python code from saving the draft.\r
+\r
+For the record, there is libabcs README [0] that clearly states:\r
+\r
+~~~ snip ~~~\r
+Never call exit(), abort(), be very careful with assert()\r
+  - Always return error codes.\r
+  - Libraries need to be safe for usage in critical processes that\r
+    need to recover from errors instead of getting killed (think PID 1!).\r
+[...]\r
+Always provide logging/debugging, but do not clutter stderr\r
+  - Allow the app to hook the libs logging into its logging facility.\r
+  - Use conditional logging, do not filter too late.\r
+  - Do not burn cycles with printf() to /dev/null.\r
+  - By default: do not generate any output on stdout/stderr.\r
+~~~ snap ~~~\r
+\r
+>This hasn't been fixed because it derives from an interface flaw.\r
+\r
+Yes. And the interface flaw is the way error reporting is done within\r
+libnotmuch. I've mentioned this once on the list and received little\r
+feedback wrt how we can fix this kind problems if we need to change\r
+the api to do so.\r
+\r
+>As always, patches welcome!\r
+\r
+Well, hacking on c code in my free time is not my idea of fun and I'm\r
+not familiar with the code base, so I'd appreciate it if someone who\r
+is in a better position to whip up a patch would step up and do so.\r
+\r
+Cheers,\r
+Justus\r
+\r
+0: https://git.kernel.org/?p=3Dlinux/kernel/git/kay/libabc.git;a=3Dblob_pla=\r
+in;f=3DREADME\r