From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 1959D431FB6 for ; Tue, 3 Dec 2013 09:49:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 KEmOenC+uRLl for ; Tue, 3 Dec 2013 09:49:50 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 96F61431FAF for ; Tue, 3 Dec 2013 09:49:50 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ec20so9463694lab.10 for ; Tue, 03 Dec 2013 09:49:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-type; bh=SKyJ7+c36w74ZEdLoL2xvX9RPwmgJKkg/UeYW4I9hTA=; b=ZSVFOOMzGZbPnGvbScXairOo9K9H1c3NX3NKObfJVIkVwUIsb3hYy4QZ6IDgz4yU5q 38It0o7m1uI4TdHkRReG+hQ7Fn7Um6AMKmDK3qALRyiVe/G7JRopiBDnW/MLo0ORwaxI swlX5XY8XjoDmXTWDPGtgPwFDWv9k652cWYE6fLgUktjQSLdv1mMrjgd5YAaYh+Je6fZ HPLvuRhUNS+baBa+TmfCfWsrRCefxdPtvYdXRh+9C3vMH0HYq6xLTG3pHsEyZ2ih0SYu 8T210Es5dnl+fwwYb2u3pAZ/Y1++dOTAgM/XCjAPCtTF67Lz/SFT2vIqE0nl8nZCI4+g NJTg== X-Gm-Message-State: ALoCoQkueIEaWzHUWsE7lMZHiwSPa+TojWDoSN6AgasM9KqRHW/m8PHTdT/hs5/BDMGC3gQn2UQ1 X-Received: by 10.152.19.65 with SMTP id c1mr2218509lae.49.1386091358161; Tue, 03 Dec 2013 09:22:38 -0800 (PST) Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi. [88.195.111.91]) by mx.google.com with ESMTPSA id np10sm43623413lbb.7.2013.12.03.09.22.36 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 03 Dec 2013 09:22:37 -0800 (PST) From: Jani Nikula To: David Bremner , notmuch@notmuchmail.org Subject: Re: [PATCH 2/2] lib: introduce notmuch_database_new for initializing a database handle In-Reply-To: <87wqjm2m2q.fsf@zancas.localnet> References: <87wqjm2m2q.fsf@zancas.localnet> User-Agent: Notmuch/0.16+145~gebbaa94 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Dec 2013 19:22:32 +0200 Message-ID: <874n6pyhlz.fsf@nikula.org> 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: Tue, 03 Dec 2013 17:49:58 -0000 On Tue, 03 Dec 2013, David Bremner wrote: > The first patch looks ok. I like the new API overall. Happy to hear that. > As far as breaking contrib/notmuch-deliver, I'd rather fix > notmuch-insert than put effort into notmuch-deliver at this point. I > guess it could be a rough transition for people running notmuch-deliver > from git. Agreed. We could fix notmuch insert with patch 1/2 alone. > Jani Nikula writes: > >> +/* >> + * XXX: error handling should clean up *all* state created! >> + */ > is this a warning to future hackers or some current problem? It's a note to self and reviewers that we need to be sure this happens... I'm just saying I'm not 100% sure we're doing all of that now. >> notmuch_status_t >> -notmuch_database_open (const char *path, >> - notmuch_database_mode_t mode, >> - notmuch_database_t **database) >> +notmuch_database_open (notmuch_database_t *notmuch, const char *path, >> + notmuch_database_mode_t mode) >> >> +/* Initialize a new, empty database handle. >> + * > > I wondered about making the new documentation adhere to doxygen? I was thinking of fixing either series depending on them getting merged. I wasn't sure we'd reached consensus on doxygen yet. >> + if (notmuch_database_open (notmuch, >> + notmuch_config_get_database_path (config), >> + NOTMUCH_DATABASE_MODE_READ_ONLY)) > > Would it make any sense to migrate the mode argument to an option > setting while we're messing with the API? My gut feeling says no. Same for the path argument suggested by Tomi. What would it mean to change the mode while the database is open? Or the path? I think we'd have to check for this, and fail. Mode is only meaningful for open, and path for open, create and compact. I think adding such state modifiers would make the interface feel more complex, but I'm open to arguments to the contrary. BR, Jani.