DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=sender:from:to:subject:in-reply-to:references:date:message-id
	:mime-version:content-type;
	b=g/NQR/49zw1zCMW7/pz+OcUULDJRwQY3RaXHXlz9s8s0YBLHAGY91F0xU3qUTaOPjo
	fxFjK8ZEalKaA08SbR2dnu7mBdHQDKZKJNIGg9p1g1P01wWLJ2+usKzUsIjZfu+FoDDQ
	OKCSG1dD8lbyysCaGZRGE3p8BnWIk0sDXp+ys=
Sender: Jed Brown <five9a2@gmail.com>
From: Jed Brown <jed@59A2.org>
To: David Bremner <bremner@unb.ca>, notmuch@notmuchmail.org
In-Reply-To: <87r5prcvtx.fsf@rocinante.cs.unb.ca>
References: <871vhwei6n.fsf@59A2.org> <87ockva36t.fsf@59A2.org>
	<87r5prcvtx.fsf@rocinante.cs.unb.ca>
Date: Fri, 15 Jan 2010 15:20:36 +0100
Message-ID: <87ljfza1qj.fsf@59A2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] asynch operations protocol
Precedence: list

On Fri, 15 Jan 2010 09:59:54 -0400, David Bremner <bremner@unb.ca> wrote:
> 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.

The asynchronous interface I work with most is MPI.  There you get a
Request object when the operation is initiated and you can
{test,block}{one,some,any,all}, where the latter takes a list of
requests.  These variants are all useful, but of course they could be
implemented as needed.  I don't think that being able to support these
variants places any particular burden on the design.

I believe in performing operations with appropriate granularity, so I
wouldn't expect cases where you need to manage thousands of active
requests, thus I'm not sure the "session" grouping offers any real
benefit.  In any case, I'm not in favor of a single global flush.

Jed