Re: bug#6214: 23.1; json-read-string crashes emacs with long string
[notmuch-archives.git] / 11 / d680eb384ba54da6e5a08645f422f99cbae9ee
1 Return-Path: <bremner@pivot.cs.unb.ca>\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 5DA59431FBC\r
6         for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:02:10 -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.049\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5\r
12         tests=[AWL=-0.050, 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 YIgMXyB4f7ZN for <notmuch@notmuchmail.org>;\r
16         Fri, 15 Jan 2010 06:02:09 -0800 (PST)\r
17 Received: from pivot.cs.unb.ca (pivot.cs.unb.ca [131.202.240.57])\r
18         by olra.theworths.org (Postfix) with ESMTP id 6D5AD431FAE\r
19         for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 06:02:09 -0800 (PST)\r
20 Received: from\r
21         fctnnbsc30w-142167190143.pppoe-dynamic.high-speed.nb.bellaliant.net\r
22         ([142.167.190.143] helo=rocinante.cs.unb.ca)\r
23         by pivot.cs.unb.ca with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)\r
24         (Exim 4.69) (envelope-from <bremner@pivot.cs.unb.ca>)\r
25         id 1NVmka-0001Wi-Ib; Fri, 15 Jan 2010 10:02:08 -0400\r
26 Received: from bremner by rocinante.cs.unb.ca with local (Exim 4.71)\r
27         (envelope-from <bremner@rocinante.cs.unb.ca>)\r
28         id 1NVmiQ-0001fj-UM; Fri, 15 Jan 2010 09:59:54 -0400\r
29 From: David Bremner <bremner@unb.ca>\r
30 To: Jed Brown <jed@59A2.org>, notmuch@notmuchmail.org\r
31 In-Reply-To: <87ockva36t.fsf@59A2.org>\r
32 References: <871vhwei6n.fsf@59A2.org> <87ockva36t.fsf@59A2.org>\r
33 Date: Fri, 15 Jan 2010 09:59:54 -0400\r
34 Message-ID: <87r5prcvtx.fsf@rocinante.cs.unb.ca>\r
35 MIME-Version: 1.0\r
36 Content-Type: text/plain; charset=us-ascii\r
37 X-Sender-Verified: bremner@pivot.cs.unb.ca\r
38 Subject: [notmuch] asynch operations protocol\r
39 X-BeenThere: notmuch@notmuchmail.org\r
40 X-Mailman-Version: 2.1.13\r
41 Precedence: list\r
42 List-Id: "Use and development of the notmuch mail system."\r
43         <notmuch.notmuchmail.org>\r
44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
45         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
47 List-Post: <mailto:notmuch@notmuchmail.org>\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
50         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
51 X-List-Received-Date: Fri, 15 Jan 2010 14:02:10 -0000\r
52 \r
53 On Fri, 15 Jan 2010 14:49:14 +0100, Jed Brown <jed@59A2.org> wrote:\r
54 > It wouldn't bother me at all if I lost my last few seconds of\r
55 > interactive tagging due to something catastrophic like losing power.  I\r
56 > think there is still (post #250) a case for supporting some asynchronous\r
57 > operations.\r
58 \r
59 I was wondering what the protocol would be like for non-blocking\r
60 commands to a notmuch daemon. I have no experience with these things,\r
61 but I was thinking something along the lines of (not worrying about wire\r
62 encoding)\r
63 \r
64 open_session  - basically just generates a unique id to allow grabbing\r
65               results of commands to be collected.\r
66 \r
67 queue command session arguments\r
68      \r
69         I guess the command dispatcher could just be a thin replacement for\r
70         command-line argument parsing.\r
71 \r
72 gather session\r
73        return all output from session \r
74 \r
75 flush session\r
76 \r
77 close session\r
78 \r
79 Is this over/under engineered?  I spent roughly as long on the design as\r
80 it took me to type :). Maybe the whole session id thing is redundant and\r
81 could be done at the socket level. Or, getting more serious about the\r
82 whole thing, maybe each queue operation should return an identifier.\r
83 \r
84 OK, discuss amongst yourselves ;)\r
85 \r
86 d\r
87 \r
88 \r
89 \r
90 \r
91 \r
92 \r