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 5DA59431FBC for ; Fri, 15 Jan 2010 06:02:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_50=0.001] autolearn=ham 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 YIgMXyB4f7ZN for ; Fri, 15 Jan 2010 06:02:09 -0800 (PST) Received: from pivot.cs.unb.ca (pivot.cs.unb.ca [131.202.240.57]) by olra.theworths.org (Postfix) with ESMTP id 6D5AD431FAE for ; Fri, 15 Jan 2010 06:02:09 -0800 (PST) Received: from fctnnbsc30w-142167190143.pppoe-dynamic.high-speed.nb.bellaliant.net ([142.167.190.143] helo=rocinante.cs.unb.ca) by pivot.cs.unb.ca with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NVmka-0001Wi-Ib; Fri, 15 Jan 2010 10:02:08 -0400 Received: from bremner by rocinante.cs.unb.ca with local (Exim 4.71) (envelope-from ) id 1NVmiQ-0001fj-UM; Fri, 15 Jan 2010 09:59:54 -0400 From: David Bremner To: Jed Brown , notmuch@notmuchmail.org In-Reply-To: <87ockva36t.fsf@59A2.org> References: <871vhwei6n.fsf@59A2.org> <87ockva36t.fsf@59A2.org> Date: Fri, 15 Jan 2010 09:59:54 -0400 Message-ID: <87r5prcvtx.fsf@rocinante.cs.unb.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-Verified: bremner@pivot.cs.unb.ca Subject: asynch operations protocol 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: Fri, 15 Jan 2010 14:02:10 -0000 On Fri, 15 Jan 2010 14:49:14 +0100, Jed Brown wrote: > It wouldn't bother me at all if I lost my last few seconds of > interactive tagging due to something catastrophic like losing power. I > think there is still (post #250) a case for supporting some asynchronous > operations. I was wondering what the protocol would be like for non-blocking commands to a notmuch daemon. I have no experience with these things, but I was thinking something along the lines of (not worrying about wire encoding) open_session - basically just generates a unique id to allow grabbing results of commands to be collected. queue command session arguments I guess the command dispatcher could just be a thin replacement for command-line argument parsing. gather session return all output from session flush session close session Is this over/under engineered? I spent roughly as long on the design as it took me to type :). Maybe the whole session id thing is redundant and could be done at the socket level. Or, getting more serious about the whole thing, maybe each queue operation should return an identifier. OK, discuss amongst yourselves ;) d