database error
[notmuch-archives.git] / 13 / 7aff744a05578cd1fab454a6771914ae8ec072
1 Return-Path: <prvs=014af3962=jrosenthal@jhu.edu>\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 5391E431FB6\r
6         for <notmuch@notmuchmail.org>; Wed,  9 Feb 2011 13:13:16 -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: -2.3\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\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 pZGcSmqsPUfx for <notmuch@notmuchmail.org>;\r
16         Wed,  9 Feb 2011 13:13:15 -0800 (PST)\r
17 Received: from ipex3.johnshopkins.edu (ipex3.johnshopkins.edu\r
18         [128.220.161.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
19         (No client certificate requested)\r
20         by olra.theworths.org (Postfix) with ESMTPS id 037B7431FB5\r
21         for <notmuch@notmuchmail.org>; Wed,  9 Feb 2011 13:13:14 -0800 (PST)\r
22 X-IronPort-Anti-Spam-Filtered: true\r
23 X-IronPort-Anti-Spam-Result: ApsEACuSUk0KoSAO/2dsb2JhbACmTbMJiGmFXASEf4Zx\r
24 X-IronPort-AV: E=Sophos;i="4.60,447,1291611600"; d="scan'208";a="75822139"\r
25 Received: from watt.hwcampus.jhu.edu ([10.161.32.14])\r
26         by ipex3.johnshopkins.edu with ESMTP/TLS/ADH-AES256-SHA;\r
27         09 Feb 2011 16:13:14 -0500\r
28 Received: by watt.hwcampus.jhu.edu (Postfix, from userid 502)\r
29         id 1634F7AC9A2; Wed,  9 Feb 2011 16:13:13 -0500 (EST)\r
30 From: Jesse Rosenthal <jrosenthal@jhu.edu>\r
31 To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
32 Subject: Re: Remote usage script updated\r
33 In-Reply-To: <87tygiowyi.fsf@wsheee.2x.cz>\r
34 References: <87oc72xs35.fsf@lucky.home> <87aaibylqe.fsf@steelpick.2x.cz>\r
35         <87tygiowyi.fsf@wsheee.2x.cz>\r
36 User-Agent: Notmuch/0.5-56-g74cb76a (http://notmuchmail.org) Emacs/23.2.1\r
37         (x86_64-apple-darwin)\r
38 Date: Wed, 09 Feb 2011 16:13:13 -0500\r
39 Message-ID: <m1k4h8syhi.fsf@watt.hwcampus.jhu.edu>\r
40 MIME-Version: 1.0\r
41 Content-Type: text/plain; charset=us-ascii\r
42 X-BeenThere: notmuch@notmuchmail.org\r
43 X-Mailman-Version: 2.1.13\r
44 Precedence: list\r
45 List-Id: "Use and development of the notmuch mail system."\r
46         <notmuch.notmuchmail.org>\r
47 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
48         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
49 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
50 List-Post: <mailto:notmuch@notmuchmail.org>\r
51 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
52 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
53         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
54 X-List-Received-Date: Wed, 09 Feb 2011 21:13:16 -0000\r
55 \r
56 Michal,\r
57 \r
58 On Sun, 06 Feb 2011 00:58:29 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
59 > Hmm, this code worked well with dropbear ssh server but it seems that\r
60 > with openssh server the result is not that good. Namely, if the master\r
61 > connection is dead, the command running true blocked for a long time.\r
62 \r
63 Seemed to work okay for me when I played around with it a bit (in\r
64 different circumstances, and with a confused laptop waking up from\r
65 hibernation). But I'll hold off on updating it till I can figure out the\r
66 most reliable way.\r
67 \r
68 I'll definitely take your suggestion to use printf instead of manually\r
69 escaping characters. \r
70 \r
71 Thanks, in any event, for your suggestions!\r
72 \r
73 By the way, I've also realized that most attachment downloading is done\r
74 not by "--format=raw" but by "notmuch part". It's possible to do caching\r
75 there as well. There are a few options there:\r
76 \r
77   * One option would be to just cache by the attachment number -- but\r
78     this is very fragile if you delete an attachment through mutt or\r
79     some other client that allows it.\r
80 \r
81   * cache by the hash of the attachment. The idea is that asking the\r
82     server to fetch it, hash it, and send the hash would still save\r
83     time over sending the whole attachment. Probably -- though most\r
84     attachments are small enough and most connections are fast enough\r
85     that this might not actually matter.\r
86 \r
87   * Actually stick the attachment hash in the json output in the first\r
88     place. But this would be a lot of trouble for a small gain for\r
89     very few.\r
90 \r
91 It would come in handy when I'm trying to get a biggish pdf over a bus's\r
92 slow wireless connection. But it's certainly not a priority.\r
93 \r
94 Best,\r
95 Jesse\r