7f/2d50b86fccaeb22e04f8bf75ba01c8c4f3d564

   1 Return-Path: <teythoon@jade-hamburg.de>\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 D30A7431FB6\r
   6         for <notmuch@notmuchmail.org>; Wed, 22 Feb 2012 07:17:54 -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\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id rWDbHpsuGS1d for <notmuch@notmuchmail.org>;\r
  16         Wed, 22 Feb 2012 07:17:54 -0800 (PST)\r
  17 Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id 0F90E431FAE\r
  21         for <notmuch@notmuchmail.org>; Wed, 22 Feb 2012 07:17:54 -0800 (PST)\r
  22 Received: from mail.jade-hamburg.de (unknown [85.183.11.228])\r
  23         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  24         (No client certificate requested)\r
  25         by mail.cryptobitch.de (Postfix) with ESMTPSA id 64D6453133C\r
  26         for <notmuch@notmuchmail.org>; Wed, 22 Feb 2012 16:17:51 +0100 (CET)\r
  27 Received: by mail.jade-hamburg.de (Postfix, from userid 401)\r
  28         id D054EDF2A9; Wed, 22 Feb 2012 16:17:50 +0100 (CET)\r
  29 Received: from thinkbox.jade-hamburg.de (unknown [85.183.11.228])\r
  30         (using TLSv1 with cipher AES256-SHA (256/256 bits))\r
  31         (No client certificate requested) (Authenticated sender: teythoon)\r
  32         by mail.jade-hamburg.de (Postfix) with ESMTPSA id 437FCDF2A5;\r
  33         Wed, 22 Feb 2012 16:17:48 +0100 (CET)\r
  34 Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.77)\r
  35         (envelope-from <teythoon@thinkbox.jade-hamburg.de>)\r
  36         id 1S0Dwv-0005pH-GE; Wed, 22 Feb 2012 16:17:45 +0100\r
  37 Content-Type: text/plain; charset="utf-8"\r
  38 MIME-Version: 1.0\r
  39 Content-Transfer-Encoding: quoted-printable\r
  40 To: Austin Clements <amdragon@MIT.EDU>, \r
  41 From: Justus Winter <4winter@informatik.uni-hamburg.de>\r
  42 In-Reply-To: <20120221155312.GB30513@mit.edu>\r
  43 References: <20120221002921.8534.57091@thinkbox.jade-hamburg.de>\r
  44         <20120221155312.GB30513@mit.edu>\r
  45 Message-ID: <20120222151745.4213.93513@thinkbox.jade-hamburg.de>\r
  46 User-Agent: alot/0.21+\r
  47 Subject: Re: notmuch as a shared object aka library knigge\r
  48 Date: Wed, 22 Feb 2012 16:17:45 +0100\r
  49 Cc: notmuch mailing list <notmuch@notmuchmail.org>\r
  50 X-BeenThere: notmuch@notmuchmail.org\r
  51 X-Mailman-Version: 2.1.13\r
  52 Precedence: list\r
  53 List-Id: "Use and development of the notmuch mail system."\r
  54         <notmuch.notmuchmail.org>\r
  55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  58 List-Post: <mailto:notmuch@notmuchmail.org>\r
  59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  62 X-List-Received-Date: Wed, 22 Feb 2012 15:17:55 -0000\r
  63 \r
  64 Quoting Austin Clements (2012-02-21 16:53:12)\r
  65 >Quoth Justus Winter on Feb 21 at  1:29 am:\r
  66 >> Hi fellow notmuchrs,\r
  67 >> =\r
  68 \r
  69 >> while going through the python bindings I recently came across the\r
  70 >> following note in the documentation for the Database.get_directory\r
  71 >> function [0]:\r
  72 >> =\r
  73 \r
  74 >> ~~~ snip ~~~\r
  75 >> Warning\r
  76 >> =\r
  77 \r
  78 >> This call needs a writable database in Database.MODE.READ_WRITE\r
  79 >> mode. The underlying library will exit the program if this method is\r
  80 >> used on a read-only database!\r
  81 >> ~~~ snap ~~~\r
  82 >\r
  83 >This is a bug and should be thought of as such.\r
  84 \r
  85 Agreed.\r
  86 \r
  87 >INTERNAL_ERROR should\r
  88 >only be used for internal library inconsistencies (e.g., things that\r
  89 >should never ever happen) [...]\r
  90 \r
  91 Well, I do not agree. If there is a inconsitency within the library\r
  92 that library should report this to the caller and it is totally okay\r
  93 to say that if the callee ignores this error, bad things will happen\r
  94 (i.e. we're in unspecified behavior territory here).\r
  95 \r
  96 It is still not okay to kill the whole process. Imagine you're using\r
  97 the alot mail client that uses libnotmuch through the python bindings\r
  98 and you've just finished writing a letter when libnotmuch decides to\r
  99 commit suicide and prevent the python code from saving the draft.\r
 100 \r
 101 For the record, there is libabcs README [0] that clearly states:\r
 102 \r
 103 ~~~ snip ~~~\r
 104 Never call exit(), abort(), be very careful with assert()\r
 105   - Always return error codes.\r
 106   - Libraries need to be safe for usage in critical processes that\r
 107     need to recover from errors instead of getting killed (think PID 1!).\r
 108 [...]\r
 109 Always provide logging/debugging, but do not clutter stderr\r
 110   - Allow the app to hook the libs logging into its logging facility.\r
 111   - Use conditional logging, do not filter too late.\r
 112   - Do not burn cycles with printf() to /dev/null.\r
 113   - By default: do not generate any output on stdout/stderr.\r
 114 ~~~ snap ~~~\r
 115 \r
 116 >This hasn't been fixed because it derives from an interface flaw.\r
 117 \r
 118 Yes. And the interface flaw is the way error reporting is done within\r
 119 libnotmuch. I've mentioned this once on the list and received little\r
 120 feedback wrt how we can fix this kind problems if we need to change\r
 121 the api to do so.\r
 122 \r
 123 >As always, patches welcome!\r
 124 \r
 125 Well, hacking on c code in my free time is not my idea of fun and I'm\r
 126 not familiar with the code base, so I'd appreciate it if someone who\r
 127 is in a better position to whip up a patch would step up and do so.\r
 128 \r
 129 Cheers,\r
 130 Justus\r
 131 \r
 132 0: https://git.kernel.org/?p=3Dlinux/kernel/git/kay/libabc.git;a=3Dblob_pla=\r
 133 in;f=3DREADME\r