Re: notmuch-search-toggle-order and notmuch-tree
[notmuch-archives.git] / cd / 8d4754dd55964c88090b57089c6f03e64345a8
1 Return-Path: <five9a2@gmail.com>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id EA725431FBC\r
6         for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:18:59 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.047\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5\r
12         tests=[AWL=-0.048, BAYES_50=0.001] autolearn=ham\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id X8EOYp+Td5sV for <notmuch@notmuchmail.org>;\r
16         Fri, 15 Jan 2010 06:18:59 -0800 (PST)\r
17 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159])\r
18         by olra.theworths.org (Postfix) with ESMTP id 21545431FAE\r
19         for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:18:59 -0800 (PST)\r
20 Received: by fg-out-1718.google.com with SMTP id e12so197098fga.2\r
21         for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:18:58 -0800 (PST)\r
22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
23         h=domainkey-signature:received:received:sender:from:to:subject\r
24         :in-reply-to:references:date:message-id:mime-version:content-type;\r
25         bh=rpW4gS0oj6E0+tHSeaFP5A1dAPPfM+eQdlwepAb1iEs=;\r
26         b=xGU0cbO3D/Jlib+dOX1HS8/vp2zWt5sZ9JMTLrnmSBz+9+SOztrdqQW1IVGiE8P9km\r
27         4CNfIsS22GpGasr6x/ayhwgZPUhzkPs7W+PJgZTpFjk84+My/id1DyfVVVIXTG4PWn8v\r
28         GdNrPaEgtUtoyhU8BoEEY08rLTIm9nqnFgtXY=\r
29 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
30         h=sender:from:to:subject:in-reply-to:references:date:message-id\r
31         :mime-version:content-type;\r
32         b=g/NQR/49zw1zCMW7/pz+OcUULDJRwQY3RaXHXlz9s8s0YBLHAGY91F0xU3qUTaOPjo\r
33         fxFjK8ZEalKaA08SbR2dnu7mBdHQDKZKJNIGg9p1g1P01wWLJ2+usKzUsIjZfu+FoDDQ\r
34         OKCSG1dD8lbyysCaGZRGE3p8BnWIk0sDXp+ys=\r
35 Received: by 10.223.2.69 with SMTP id 5mr2673707fai.88.1263565138072;\r
36         Fri, 15 Jan 2010 06:18:58 -0800 (PST)\r
37 Received: from kunyang (vawpc43.ethz.ch [129.132.59.11])\r
38         by mx.google.com with ESMTPS id 9sm2436784fks.52.2010.01.15.06.18.55\r
39         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
40         Fri, 15 Jan 2010 06:18:56 -0800 (PST)\r
41 Sender: Jed Brown <five9a2@gmail.com>\r
42 From: Jed Brown <jed@59A2.org>\r
43 To: David Bremner <bremner@unb.ca>, notmuch@notmuchmail.org\r
44 In-Reply-To: <87r5prcvtx.fsf@rocinante.cs.unb.ca>\r
45 References: <871vhwei6n.fsf@59A2.org> <87ockva36t.fsf@59A2.org>\r
46         <87r5prcvtx.fsf@rocinante.cs.unb.ca>\r
47 Date: Fri, 15 Jan 2010 15:20:36 +0100\r
48 Message-ID: <87ljfza1qj.fsf@59A2.org>\r
49 MIME-Version: 1.0\r
50 Content-Type: text/plain; charset=us-ascii\r
51 Subject: Re: [notmuch] asynch operations protocol\r
52 X-BeenThere: notmuch@notmuchmail.org\r
53 X-Mailman-Version: 2.1.13\r
54 Precedence: list\r
55 List-Id: "Use and development of the notmuch mail system."\r
56         <notmuch.notmuchmail.org>\r
57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
60 List-Post: <mailto:notmuch@notmuchmail.org>\r
61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
64 X-List-Received-Date: Fri, 15 Jan 2010 14:19:00 -0000\r
65 \r
66 On Fri, 15 Jan 2010 09:59:54 -0400, David Bremner <bremner@unb.ca> wrote:\r
67 > Is this over/under engineered?  I spent roughly as long on the design as\r
68 > it took me to type :). Maybe the whole session id thing is redundant and\r
69 > could be done at the socket level. Or, getting more serious about the\r
70 > whole thing, maybe each queue operation should return an identifier.\r
71 \r
72 The asynchronous interface I work with most is MPI.  There you get a\r
73 Request object when the operation is initiated and you can\r
74 {test,block}{one,some,any,all}, where the latter takes a list of\r
75 requests.  These variants are all useful, but of course they could be\r
76 implemented as needed.  I don't think that being able to support these\r
77 variants places any particular burden on the design.\r
78 \r
79 I believe in performing operations with appropriate granularity, so I\r
80 wouldn't expect cases where you need to manage thousands of active\r
81 requests, thus I'm not sure the "session" grouping offers any real\r
82 benefit.  In any case, I'm not in favor of a single global flush.\r
83 \r
84 Jed\r