eb/263fa2fc4ce6bab752339c15cd4f8eb3e3c8a4

   1 Return-Path: <tomi.ollila@iki.fi>\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 1B2F6431FC0\r
   6         for <notmuch@notmuchmail.org>; Thu, 14 Nov 2013 09:23:33 -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 hwhfHJe9Fzbf for <notmuch@notmuchmail.org>;\r
  16         Thu, 14 Nov 2013 09:23:24 -0800 (PST)\r
  17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
  18         by olra.theworths.org (Postfix) with ESMTP id B563B431FB6\r
  19         for <notmuch@notmuchmail.org>; Thu, 14 Nov 2013 09:23:24 -0800 (PST)\r
  20 Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
  21         by guru.guru-group.fi (Postfix) with ESMTP id BE11F100033;\r
  22         Thu, 14 Nov 2013 19:23:14 +0200 (EET)\r
  23 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  24 To: David Bremner <david@tethera.net>, Jani Nikula <jani@nikula.org>,\r
  25         notmuch@notmuchmail.org\r
  26 Subject: Re: [PATCH v2 5/5] compact: provide user more information on\r
  27         after-compaction failures\r
  28 In-Reply-To: <87y54rx8sf.fsf@unb.ca>\r
  29 References: <1384362167-12740-1-git-send-email-tomi.ollila@iki.fi>\r
  30         <1384362167-12740-6-git-send-email-tomi.ollila@iki.fi>\r
  31         <871u2jnkai.fsf@nikula.org> <87y54rx8sf.fsf@unb.ca>\r
  32 User-Agent: Notmuch/0.16+174~g9a06aa2 (http://notmuchmail.org) Emacs/24.3.1\r
  33         (x86_64-unknown-linux-gnu)\r
  34 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  35         $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  36         !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  37 Date: Thu, 14 Nov 2013 19:23:14 +0200\r
  38 Message-ID: <m28uwquccd.fsf@guru.guru-group.fi>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: text/plain\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Thu, 14 Nov 2013 17:23:33 -0000\r
  54 \r
  55 On Thu, Nov 14 2013, David Bremner <david@tethera.net> wrote:\r
  56 \r
  57 > Jani Nikula <jani@nikula.org> writes:\r
  58 >\r
  59 >> On Wed, 13 Nov 2013, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  60 >>> After database has been compacted, there are steps to put the new\r
  61 >>> database into place -- and these steps may fail. In case such\r
  62 >>> failure happens, provide better information how to resolve it.\r
  63 >>\r
  64 >> I disagree with having a library spew all this information out. For each\r
  65 >> case, I think it should be sufficient to just say what happened\r
  66 >> (e.g. "rename a -> b failed" + strerror). I don't think a library's\r
  67 >> error messages should be a tutorial on how to fix things.\r
  68 >>\r
  69 >\r
  70 > I can live with whatever the concensus level of verbosity, but not the\r
  71 > fprintf's; as I mentioned, for once we have a log hook.\r
  72 \r
  73 Jani is right there that *library* should not dump all that info\r
  74 to ... stderr. If so much info is printed, the client code should\r
  75 do that -- but doing that cleanly is not a trivial job. The idea of\r
  76 amending the namual page to inform user is a good one.\r
  77 \r
  78 The log hook in it's current form is problematic as it doesn't provide\r
  79 way to distinguish progress reporting from error reporting. Currently\r
  80 lib/database.cc writes error messages with fprintf(stderr, ...) everywhere.\r
  81 \r
  82 I suggest that this problem is fixed in one big sweep during 0.18\r
  83 development -- the suggestion Jani pastebin'd a few days ago is\r
  84 a good one and I'm willing to take part of that development...\r
  85 And now take this approach of fprintf()ing (basically I would\r
  86 also ask developers using the library wait for 0.18 before starting\r
  87 to use the compact functionality (if ever), as the we have yet\r
  88 another soname bump with changing interface coming...\r
  89 \r
  90 \r
  91 Just that the log interface needs to be in format\r
  92 \r
  93 void (*log_cb)(void * closure, int level, const char * message)\r
  94 \r
  95 And we need to decide between the (non-NIH) syslog levels vs.\r
  96 our own levels...\r
  97 \r
  98 This way we can distinguish debug (DEBUG), progress (NOTICE, INFO) \r
  99 and error (WARN, EER, CRIT, ALERT, EMERG) conditions.\r
 100 \r
 101 \r
 102 For someone who wished logf(closure, level, fmt, ...) we can provide\r
 103 helper functions\r
 104 \r
 105 _log_printf(log_cb, closure, level, fmt, ...) and\r
 106 _log_vprintf(log_cb, closure, level, fmt, ap)\r
 107 \r
 108 \r
 109 >\r
 110 > That might also somewhat comfort Jani, since the library client has the\r
 111 > option of ignoring the spewing.\r
 112 \r
 113 String maybe!\r
 114 \r
 115 >\r
 116 > d\r
 117 \r
 118 Tomi\r
 119 \r