[notmuch] asynch operations protocol

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