From: Tomi Ollila Date: Thu, 14 Nov 2013 17:23:14 +0000 (+0200) Subject: Re: [PATCH v2 5/5] compact: provide user more information on after-compaction failures X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=ab2f1bcde077468c575eefacc7f0b328b4d8e880;p=notmuch-archives.git Re: [PATCH v2 5/5] compact: provide user more information on after-compaction failures --- diff --git a/eb/263fa2fc4ce6bab752339c15cd4f8eb3e3c8a4 b/eb/263fa2fc4ce6bab752339c15cd4f8eb3e3c8a4 new file mode 100644 index 000000000..2ca191b45 --- /dev/null +++ b/eb/263fa2fc4ce6bab752339c15cd4f8eb3e3c8a4 @@ -0,0 +1,119 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 1B2F6431FC0 + for ; Thu, 14 Nov 2013 09:23:33 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id hwhfHJe9Fzbf for ; + Thu, 14 Nov 2013 09:23:24 -0800 (PST) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id B563B431FB6 + for ; Thu, 14 Nov 2013 09:23:24 -0800 (PST) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id BE11F100033; + Thu, 14 Nov 2013 19:23:14 +0200 (EET) +From: Tomi Ollila +To: David Bremner , Jani Nikula , + notmuch@notmuchmail.org +Subject: Re: [PATCH v2 5/5] compact: provide user more information on + after-compaction failures +In-Reply-To: <87y54rx8sf.fsf@unb.ca> +References: <1384362167-12740-1-git-send-email-tomi.ollila@iki.fi> + <1384362167-12740-6-git-send-email-tomi.ollila@iki.fi> + <871u2jnkai.fsf@nikula.org> <87y54rx8sf.fsf@unb.ca> +User-Agent: Notmuch/0.16+174~g9a06aa2 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-unknown-linux-gnu) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 14 Nov 2013 17:23:33 -0000 + +On Thu, Nov 14 2013, David Bremner wrote: + +> Jani Nikula writes: +> +>> On Wed, 13 Nov 2013, Tomi Ollila wrote: +>>> After database has been compacted, there are steps to put the new +>>> database into place -- and these steps may fail. In case such +>>> failure happens, provide better information how to resolve it. +>> +>> I disagree with having a library spew all this information out. For each +>> case, I think it should be sufficient to just say what happened +>> (e.g. "rename a -> b failed" + strerror). I don't think a library's +>> error messages should be a tutorial on how to fix things. +>> +> +> I can live with whatever the concensus level of verbosity, but not the +> fprintf's; as I mentioned, for once we have a log hook. + +Jani is right there that *library* should not dump all that info +to ... stderr. If so much info is printed, the client code should +do that -- but doing that cleanly is not a trivial job. The idea of +amending the namual page to inform user is a good one. + +The log hook in it's current form is problematic as it doesn't provide +way to distinguish progress reporting from error reporting. Currently +lib/database.cc writes error messages with fprintf(stderr, ...) everywhere. + +I suggest that this problem is fixed in one big sweep during 0.18 +development -- the suggestion Jani pastebin'd a few days ago is +a good one and I'm willing to take part of that development... +And now take this approach of fprintf()ing (basically I would +also ask developers using the library wait for 0.18 before starting +to use the compact functionality (if ever), as the we have yet +another soname bump with changing interface coming... + + +Just that the log interface needs to be in format + +void (*log_cb)(void * closure, int level, const char * message) + +And we need to decide between the (non-NIH) syslog levels vs. +our own levels... + +This way we can distinguish debug (DEBUG), progress (NOTICE, INFO) +and error (WARN, EER, CRIT, ALERT, EMERG) conditions. + + +For someone who wished logf(closure, level, fmt, ...) we can provide +helper functions + +_log_printf(log_cb, closure, level, fmt, ...) and +_log_vprintf(log_cb, closure, level, fmt, ap) + + +> +> That might also somewhat comfort Jani, since the library client has the +> option of ignoring the spewing. + +String maybe! + +> +> d + +Tomi +