1 Return-Path: <notmuch@stoakes.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 75D95429E20
\r
6 for <notmuch@notmuchmail.org>; Mon, 24 Jan 2011 15:47:07 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=1.274 tagged_above=-999 required=5
\r
12 tests=[RDNS_NONE=1.274] 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 OmYCuNNdvoE0 for <notmuch@notmuchmail.org>;
\r
16 Mon, 24 Jan 2011 15:47:06 -0800 (PST)
\r
17 X-Greylist: delayed 529 seconds by postgrey-1.32 at olra;
\r
18 Mon, 24 Jan 2011 15:47:06 PST
\r
19 Received: from narco.pvt.stoakes.net (unknown [169.222.11.37])
\r
20 by olra.theworths.org (Postfix) with ESMTP id 04DE9431FB6
\r
21 for <notmuch@notmuchmail.org>; Mon, 24 Jan 2011 15:47:05 -0800 (PST)
\r
22 Received: by narco.pvt.stoakes.net (Postfix, from userid 1000)
\r
23 id B2A4D102E6C; Tue, 25 Jan 2011 10:08:12 +1030 (CST)
\r
24 Date: Tue, 25 Jan 2011 10:08:12 +1030
\r
25 From: Tim Stoakes <notmuch@stoakes.net>
\r
26 To: David Mazieres expires 2011-02-24 PST
\r
27 <mazieres-468jumwyp2ei6jwxn8m5vrkyja@temporary-address.scs.stanford.edu>
\r
28 Subject: Re: Tag timestamps and synchronization
\r
29 Message-ID: <20110124233812.GB23628@mail.stoakes.net>
\r
30 References: <x78vyanmnb.wl@ta.scs.stanford.edu>
\r
32 Content-Type: text/plain; charset=us-ascii
\r
33 Content-Disposition: inline
\r
34 In-Reply-To: <x78vyanmnb.wl@ta.scs.stanford.edu>
\r
35 User-Agent: Mutt/1.5.21 (2010-09-15)
\r
36 Cc: notmuch@notmuchmail.org
\r
37 X-BeenThere: notmuch@notmuchmail.org
\r
38 X-Mailman-Version: 2.1.13
\r
40 List-Id: "Use and development of the notmuch mail system."
\r
41 <notmuch.notmuchmail.org>
\r
42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
43 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
44 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
45 List-Post: <mailto:notmuch@notmuchmail.org>
\r
46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
48 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
49 X-List-Received-Date: Mon, 24 Jan 2011 23:47:07 -0000
\r
51 dm-list-email-notmuch@scs.stanford.edu(dm-list-email-notmuch@scs.stanford.edu)@240111-11:10:
\r
52 > One of the features I would like to see from notmuch is an easier
\r
53 > ability to synchronize tags across machines. At the very least, I
\r
54 > would need either incremental dump and restore, or some way to
\r
55 > communicate arbitrary tags to a local imap server that shares
\r
56 > notmuch's maildir (much as notmuch currently syncs the standard tags),
\r
57 > so that I synchronize two maildirs with a tool like offlineimap.
\r
61 I do something like this by using some shell scripts with formail, to
\r
62 'store' notmuch tags into the X-Label headers of the individual mails.
\r
63 Offlineimap then syncs these headers. If I need the tags to become
\r
64 notmuch-ified on the target, I just scan all the mail's X-Label headers.
\r
66 (Actually it's better than this, since I use maildrop to set notmuch
\r
67 tags with notmuch-deliver, *and* set X-Label headers to the same thing,
\r
68 at mail delivery time. Then I use keybindings and shell scripts in mutt
\r
69 such that whenever I retag a message, it is pushed to both notmuch and
\r
72 I'm happy to share this hack glue if it would help.
\r
74 This is not great for a few reasons - there are a ton of moving parts,
\r
75 and some double-work. If notmuch could index X-Label headers (a coming
\r
76 feature I hear) then this would be much cleaner.
\r
78 This is just one way of doing it, that works for me...
\r
82 > As Carl pointed out to me in private email, there has been some
\r
83 > previous discussion in the following thread:
\r
85 > notmuch show id:87hbfnmiux.fsf@yoom.home.cworth.org
\r
87 > Based on that thread, there seems to be some desire for notmuch to
\r
88 > keep track of a per-message timestamp when the flags were last
\r
89 > updated. This would allow much easier expiration for people who want
\r
90 > the deleted tag. It would also allow incremental dump and restore of
\r
91 > tags, which is exactly what I need to sync tags across servers with
\r
92 > reasonable amounts of bandwidth.
\r
94 > Metadata timestamps are one of those things that probably have a lot
\r
95 > of different applications, so since Carl is considering a new database
\r
96 > format for the next release anyway, perhaps it also makes sense to add
\r
97 > a metadata change time for each messages.
\r
99 > The timestamp would be included in "dump" output, and you could
\r
100 > request a dump of changes since a particular time. On restore, you
\r
101 > might have several options:
\r
103 > - overwrite: always set the new tags and timestamp in the database
\r
104 > to the value in the restore data.
\r
106 > - update: always set the tags, but update the to the current time.
\r
108 > - conditional T: update only if the message metadata has not been
\r
109 > updated since time T.
\r
111 > To sync flags, then you just need to keep track of the last time you
\r
112 > synced with a particular server--call this time T. Do a dump since
\r
113 > time T, upload to server, do a conditional restore for time T on
\r
114 > server. Finally do a partial dump from time T on the server and an
\r
115 > overwrite import on the client. (This policy makes changes on the
\r
116 > server always override conflicting ones on the client--perhaps people
\r
117 > want other policies, like union of the tags, etc.)
\r
120 > Second, there seems to be some desire in that thread to sync with IMAP
\r
121 > flags. This would be particularly great, but the easies way to do it
\r
122 > is probably *not* to try to implement IMAP, but rather to use an
\r
123 > existing IMAP server and just modify the maildir so that the IMAP
\r
124 > server will pick up the flags.
\r
126 > In the case of dovecot, the arbitrary tag format is very simple. Each
\r
127 > maildir has a file called dovecot-keywords mapping numbers 0, 1,
\r
128 > ... to keywords. Then mail file names contain lower-case letters for
\r
129 > the flags they are marked with--0 => a, 1 => b, etc.--allowing up to
\r
130 > 26 arbitrary tags for each maildir. One could probably sync to
\r
131 > dovecot's maildir format relatively easily in a script given
\r
132 > incremental dump and restore of tags. Or possibly notmuch could
\r
133 > natively support dovecot as one of multiple back-end tag storage
\r
136 > Having a static tag mapping in the .notmuch-config file would be much
\r
137 > better than hard-coding flag2tag. However, I'm not sure it's
\r
138 > sufficient. The reason is that if you ever completely delete a tag
\r
139 > (e.g., you have "todo", and "meeting" tags and periodically have no
\r
140 > messages in either categories in a given mail folder), then an IMAP
\r
141 > server like dovecot might end up re-allocating the letters
\r
142 > corresponding to those tags in a different order. Also, at least for
\r
143 > dovecot, the flag mappings are per-folder, which you kind of want
\r
144 > since you are limited to 26 non-standard tags, so global values might
\r
147 > I'm curious to hear people's thoughts/reactions?
\r
projects / notmuch-archives.git / blob