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 02645431FC2 for ; Sat, 17 Jan 2015 04:29:41 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 2.438 X-Spam-Level: ** X-Spam-Status: No, score=2.438 tagged_above=-999 required=5 tests=[DNS_FROM_AHBL_RHSBL=2.438] 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 8riIKuVUO6ph for ; Sat, 17 Jan 2015 04:29:37 -0800 (PST) Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id CC636431FAF for ; Sat, 17 Jan 2015 04:29:37 -0800 (PST) Received: from remotemail by yantan.tethera.net with local (Exim 4.80) (envelope-from ) id 1YCSVU-0006tU-RM; Sat, 17 Jan 2015 08:29:36 -0400 Received: (nullmailer pid 25526 invoked by uid 1000); Sat, 17 Jan 2015 12:29:31 -0000 From: David Bremner To: Gaute Hope , notmuch Subject: Re: DatabaseModifiedErrors causing troubles In-Reply-To: <1421493070-astroid-1-4x8pflg7mc-1327@strange> References: <87bnmkgr57.fsf@maritornes.cs.unb.ca> <1421493070-astroid-1-4x8pflg7mc-1327@strange> User-Agent: Notmuch/0.19+21~g71fb37d (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 17 Jan 2015 13:29:31 +0100 Message-ID: <87fvb9bnf8.fsf@maritornes.cs.unb.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: Sat, 17 Jan 2015 12:29:41 -0000 Gaute Hope writes: > > Hi David, > > Would it be possible with an error code that I could compare against in > stead? It would then work a bit like a global instance of the gmime > error. It could even be a preparation step against a gmime-error-style > solution in the far future. > > I am sure you know all the bad reasons for using a strcmp with strings > such as small (subtle) changes making them useless or future > localization of notmuch. This solution is in my opinion worse than the > current situation, it will lock things in and create problems for future > API compatability and application maintainers. I would rather wait for > or spend some time on a more general solution. I don't agree it's worse than the current situation but I take your point it isn't ideal. We could do some kind "errno" in the database structure. I think there are not that many functions with this unhelpful error return type. Based on a scan of notmuch.h, I see notmuch_query_search_threads notmuch_query_search_messages and the two count functions that I already posted API breaking patches for. It might be better just to update the API (either adding versions with error returns, or just forcing people to change) for these functions. Otherwise we have two different ways of returning status codes, and the "errno" is only used some of the time. d