Re: [notmuch] asynch operations protocol

diff --git a/cd/8d4754dd55964c88090b57089c6f03e64345a8 b/cd/8d4754dd55964c88090b57089c6f03e64345a8
new file mode 100644 (file)
index 0000000..9d530a8
--- /dev/null
+++ b/cd/8d4754dd55964c88090b57089c6f03e64345a8
@@ -0,0 +1,84 @@
+Return-Path: <five9a2@gmail.com>\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 EA725431FBC\r
+       for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:18:59 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.047\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5\r
+       tests=[AWL=-0.048, 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 X8EOYp+Td5sV for <notmuch@notmuchmail.org>;\r
+       Fri, 15 Jan 2010 06:18:59 -0800 (PST)\r
+Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159])\r
+       by olra.theworths.org (Postfix) with ESMTP id 21545431FAE\r
+       for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:18:59 -0800 (PST)\r
+Received: by fg-out-1718.google.com with SMTP id e12so197098fga.2\r
+       for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:18:58 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+       h=domainkey-signature:received:received:sender:from:to:subject\r
+       :in-reply-to:references:date:message-id:mime-version:content-type;\r
+       bh=rpW4gS0oj6E0+tHSeaFP5A1dAPPfM+eQdlwepAb1iEs=;\r
+       b=xGU0cbO3D/Jlib+dOX1HS8/vp2zWt5sZ9JMTLrnmSBz+9+SOztrdqQW1IVGiE8P9km\r
+       4CNfIsS22GpGasr6x/ayhwgZPUhzkPs7W+PJgZTpFjk84+My/id1DyfVVVIXTG4PWn8v\r
+       GdNrPaEgtUtoyhU8BoEEY08rLTIm9nqnFgtXY=\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
+       h=sender:from:to:subject:in-reply-to:references:date:message-id\r
+       :mime-version:content-type;\r
+       b=g/NQR/49zw1zCMW7/pz+OcUULDJRwQY3RaXHXlz9s8s0YBLHAGY91F0xU3qUTaOPjo\r
+       fxFjK8ZEalKaA08SbR2dnu7mBdHQDKZKJNIGg9p1g1P01wWLJ2+usKzUsIjZfu+FoDDQ\r
+       OKCSG1dD8lbyysCaGZRGE3p8BnWIk0sDXp+ys=\r
+Received: by 10.223.2.69 with SMTP id 5mr2673707fai.88.1263565138072;\r
+       Fri, 15 Jan 2010 06:18:58 -0800 (PST)\r
+Received: from kunyang (vawpc43.ethz.ch [129.132.59.11])\r
+       by mx.google.com with ESMTPS id 9sm2436784fks.52.2010.01.15.06.18.55\r
+       (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
+       Fri, 15 Jan 2010 06:18:56 -0800 (PST)\r
+Sender: Jed Brown <five9a2@gmail.com>\r
+From: Jed Brown <jed@59A2.org>\r
+To: David Bremner <bremner@unb.ca>, notmuch@notmuchmail.org\r
+In-Reply-To: <87r5prcvtx.fsf@rocinante.cs.unb.ca>\r
+References: <871vhwei6n.fsf@59A2.org> <87ockva36t.fsf@59A2.org>\r
+       <87r5prcvtx.fsf@rocinante.cs.unb.ca>\r
+Date: Fri, 15 Jan 2010 15:20:36 +0100\r
+Message-ID: <87ljfza1qj.fsf@59A2.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Subject: Re: [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:19:00 -0000\r
+\r
+On Fri, 15 Jan 2010 09:59:54 -0400, David Bremner <bremner@unb.ca> wrote:\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
+The asynchronous interface I work with most is MPI.  There you get a\r
+Request object when the operation is initiated and you can\r
+{test,block}{one,some,any,all}, where the latter takes a list of\r
+requests.  These variants are all useful, but of course they could be\r
+implemented as needed.  I don't think that being able to support these\r
+variants places any particular burden on the design.\r
+\r
+I believe in performing operations with appropriate granularity, so I\r
+wouldn't expect cases where you need to manage thousands of active\r
+requests, thus I'm not sure the "session" grouping offers any real\r
+benefit.  In any case, I'm not in favor of a single global flush.\r
+\r
+Jed\r