Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email
[notmuch-archives.git] / 47 / 51277ef23b7cd84fc326a304a7f018b9f5e6b8
1 Return-Path: <david@tethera.net>\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 1DE9A431FAF\r
6         for <notmuch@notmuchmail.org>; Fri, 11 Apr 2014 04:09:04 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
12         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 ZjtPbJ1G8cVB for <notmuch@notmuchmail.org>;\r
16         Fri, 11 Apr 2014 04:08:58 -0700 (PDT)\r
17 Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155])\r
18         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
19         (No client certificate requested)\r
20         by olra.theworths.org (Postfix) with ESMTPS id 2CFA4431FAE\r
21         for <notmuch@notmuchmail.org>; Fri, 11 Apr 2014 04:08:58 -0700 (PDT)\r
22 Received: from remotemail by yantan.tethera.net with local (Exim 4.80)\r
23         (envelope-from <david@tethera.net>)\r
24         id 1WYZKE-0004WO-4E; Fri, 11 Apr 2014 08:08:50 -0300\r
25 Received: (nullmailer pid 6460 invoked by uid 1000); Fri, 11 Apr 2014\r
26         11:08:46 -0000\r
27 From: David Bremner <david@tethera.net>\r
28 To: David Mazieres expires 2014-07-09 PDT\r
29         <mazieres-gzp7rfravpipmg73ew8cs6n6t6@temporary-address.scs.stanford.edu>,\r
30         Gaute Hope <eg@gaute.vetsj.com>\r
31 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
32         changed on disk\r
33 In-Reply-To: <87wqexnqvb.fsf@ta.scs.stanford.edu>\r
34 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
35         <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
36         <87wqexnqvb.fsf@ta.scs.stanford.edu>\r
37 User-Agent: Notmuch/0.17+180~g8977b1a (http://notmuchmail.org) Emacs/24.3.1\r
38         (x86_64-pc-linux-gnu)\r
39 Date: Fri, 11 Apr 2014 08:08:46 -0300\r
40 Message-ID: <87k3aw5dj5.fsf@zancas.localnet>\r
41 MIME-Version: 1.0\r
42 Content-Type: text/plain\r
43 Cc: notmuch <notmuch@notmuchmail.org>\r
44 X-BeenThere: notmuch@notmuchmail.org\r
45 X-Mailman-Version: 2.1.13\r
46 Precedence: list\r
47 List-Id: "Use and development of the notmuch mail system."\r
48         <notmuch.notmuchmail.org>\r
49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
52 List-Post: <mailto:notmuch@notmuchmail.org>\r
53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
56 X-List-Received-Date: Fri, 11 Apr 2014 11:09:04 -0000\r
57 \r
58 dm-list-email-notmuch@scs.stanford.edu writes:\r
59 \r
60 > Gaute Hope <eg@gaute.vetsj.com> writes:\r
61 \r
62 > Exactly.  It could be a tick, or just the current time of day if your\r
63 > clock does not go backwards.  (I'd be willing to do a full scan if the\r
64 > clock ever goes backwards.)  The advantage of time is that you don't\r
65 > have to synchronously update some counter.\r
66 \r
67 I think I'd lean towards global time so that one could use it to resolve\r
68 conflicts between changes to multiple copies of the database.\r
69 \r
70 > Making sure the write-operations update the time should be easy.  Most\r
71 > or all of the changes are probably funneled through\r
72 > _notmuch_message_sync.  Worst case, there are only 9 places in the\r
73 > source code that make use of a Xapian:WritableDatabase, so I'm pretty\r
74 > confident total changes wouldn't be much more than 50 lines of code.\r
75 \r
76 Maybe. Don't forget upgrading the database, updating the test suite, and\r
77 presumably some changes to the CLI so the new mtime can actually be\r
78 used. Not to be discouraging ;).\r
79 \r
80 > I would do it myself if there were any kind of indication that such a\r
81 > change could be upstreamed.  I brought this up in January, 2011, and\r
82 > didn't get a huge amount of interest in the ctime idea.  But I was also\r
83 > a lot less focused on what I needed.  Now that I have a working\r
84 > distributed setup and am actually using notmuch for my mail, I have a\r
85 > much better understanding of what is needed.\r
86 \r
87 In the ensuing time, nothing better has developed for tag\r
88 synchronization (my pet use case) so maybe it's time to pursue this\r
89 again.  It would be good to have some preliminary idea about the time\r
90 and space costs of adding document mtimes.  I guess database bloat\r
91 should not be too bad, since it's only 64bits (?) per mail message.\r