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 DC60B431FC0 for ; Fri, 26 Feb 2010 20:10:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_50=0.001, RDNS_DYNAMIC=0.1] autolearn=no 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 2kBjfcCDnR1A for ; Fri, 26 Feb 2010 20:10:31 -0800 (PST) Received: from hackervisions.org (67-207-143-141.slicehost.net [67.207.143.141]) by olra.theworths.org (Postfix) with ESMTP id 8C3CA431FAE for ; Fri, 26 Feb 2010 20:10:31 -0800 (PST) Received: from ool-18bd392a.dyn.optonline.net ([24.189.57.42] helo=localhost) by hv with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1NlE0Y-0005qi-DA; Fri, 26 Feb 2010 23:10:26 -0500 From: James Vasile To: Carl Worth , notmuch@notmuchmail.org In-Reply-To: <873a0n6ac8.fsf@yoom.home.cworth.org> References: <87pr3sw43a.fsf@hackervisions.org> <873a0n6ac8.fsf@yoom.home.cworth.org> Date: Fri, 26 Feb 2010 23:10:16 -0500 Message-ID: <87eik748uv.fsf@hackervisions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [notmuch] [PATCH] Add shell script notmuch-retry 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, 27 Feb 2010 04:10:32 -0000 On Fri, 26 Feb 2010 11:55:19 -0800, Carl Worth wrote: > On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile wrote: > > Maybe this retry loop should be put in notmuch itself? > > Perhaps it should. I've even imagined something that would queue a > request into a daemon if the database isn't currently available. > > But of course there are issues about whether the caller would want to > know about the locking error, (or might actually need to block until the > operation is complete). So I'm not sure about the right answer here. --block and/or --queue?