1 Return-Path: <eg@gaute.vetsj.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 21210431FAF
\r
6 for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 23:57:26 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
\r
12 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 cfyHJiruYHlt for <notmuch@notmuchmail.org>;
\r
16 Mon, 22 Sep 2014 23:57:09 -0700 (PDT)
\r
17 Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com
\r
18 [209.85.192.44]) (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 89EF1431FAE
\r
21 for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 23:57:09 -0700 (PDT)
\r
22 Received: by mail-qg0-f44.google.com with SMTP id f51so4177176qge.3
\r
23 for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 23:57:08 -0700 (PDT)
\r
24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
\r
25 d=1e100.net; s=20130820;
\r
26 h=x-gm-message-state:mime-version:in-reply-to:references:date
\r
27 :message-id:subject:from:to:cc:content-type;
\r
28 bh=bqs7RpSw4T/jZaRqde4Q+ZnDMqzMYWouvanyODghIHQ=;
\r
29 b=SH3XN7UZtLXTHZGzPyrja8W79mdxkdQxUk1GdKEPkMS5BzJxNpfr8jqw+QDhm65L3j
\r
30 LdesHP4GnJZ5u0IH2y+0QV6Nq0E9jl4btob55FNuZ7WrN7m2/16WGYcNAFe0DgHmUxo4
\r
31 gQyceNWbB7VL5+JwAYjK+uQfRC2pcrA405wdcFBuD6Dz3tirDDnNt+YkKJ6yoAzBJL9t
\r
32 wa5v+NF0tZOCfXiEJVSQeI7xXQJWMydXRx+1PJp6PioCVb/73ZSZ/1jj+Y06lX5d9wDO
\r
33 rR1/AgsHhapCun/IqB9epszmzgrkDFvPmLvq6DWhzP6AC16+oPjtclKSVVupMfl4MEPP
\r
36 ALoCoQmbhPmdvmHEI1JoECLSQ1OqSgnlGyjHpraZdrZV5u3ipXaKdTmkXdQxilJlP2MBE7Mtu0Js
\r
38 X-Received: by 10.224.46.6 with SMTP id h6mr29733002qaf.45.1411455428701; Mon,
\r
39 22 Sep 2014 23:57:08 -0700 (PDT)
\r
40 Received: by 10.96.174.104 with HTTP; Mon, 22 Sep 2014 23:57:08 -0700 (PDT)
\r
41 Received: by 10.96.174.104 with HTTP; Mon, 22 Sep 2014 23:57:08 -0700 (PDT)
\r
42 In-Reply-To: <87k34vackm.fsf@drake.dyndns.org>
\r
43 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>
\r
44 <87fviiiuzn.fsf@maritornes.cs.unb.ca>
\r
45 <CABKe4Mv6p77i5dBT9BV41hxmtrE4UPLR3NjZfpLuZDoE1KWYyA@mail.gmail.com>
\r
46 <20140801185505.GS13893@mit.edu>
\r
47 <1407313144-astroid-0-vyhth1tcrd-3835@strange>
\r
48 <1411386960-astroid-2-k1e726ut3f-2518@strange>
\r
49 <87k34vackm.fsf@drake.dyndns.org>
\r
50 Date: Tue, 23 Sep 2014 08:57:08 +0200
\r
52 <CABKe4MsXuOz2Amrw6qRxohGe7qujA3xuNFG=ENYAho9gnk72pA@mail.gmail.com>
\r
53 Subject: Re: [PATCH] Add configurable changed tag to messages that have been
\r
55 From: Gaute Hope <eg@gaute.vetsj.com>
\r
56 To: Austin Clements <aclements@csail.mit.edu>
\r
57 Content-Type: multipart/alternative; boundary=001a11c35a9c71cb080503b613b8
\r
58 Cc: notmuch <notmuch@notmuchmail.org>
\r
59 X-BeenThere: notmuch@notmuchmail.org
\r
60 X-Mailman-Version: 2.1.13
\r
62 List-Id: "Use and development of the notmuch mail system."
\r
63 <notmuch.notmuchmail.org>
\r
64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
65 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
67 List-Post: <mailto:notmuch@notmuchmail.org>
\r
68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
70 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
71 X-List-Received-Date: Tue, 23 Sep 2014 06:57:26 -0000
\r
73 --001a11c35a9c71cb080503b613b8
\r
74 Content-Type: text/plain; charset=UTF-8
\r
75 Content-Transfer-Encoding: quoted-printable
\r
77 22. sep. 2014 17:40 skrev "Austin Clements" <aclements@csail.mit.edu>
\r
80 > On Mon, 22 Sep 2014, Gaute Hope <eg@gaute.vetsj.com> wrote:
\r
81 > > Excerpts from Gaute Hope's message of August 6, 2014 10:29:
\r
82 > >> Austin Clements <amdragon@MIT.EDU> wrote on Fri, 01 Aug 2014 14:55:05
\r
84 > >>> I have a prototype implementation of message modification times on my
\r
85 > >>> lastmod-v1 branch at
\r
87 > >>> https://github.com/aclements/notmuch/tree/lastmod-v1
\r
89 > >>> It builds on my database features series that's currently awaiting
\r
92 > >>> The series uses a monotonic revision number, rather than wall-clock
\r
93 > >>> time, for reasons related to Xapian's concurrent control and detailed
\r
94 > >>> in the main commit's commit message. The implementation isn't quite
\r
95 > >>> useful from the CLI yet because I haven't added any way to query the
\r
96 > >>> database's current revision number. (I'm still thinking about how I
\r
97 > >>> want to do this, since search/show don't have a good way to deliver
\r
98 > >>> "additional" information right now. I might just add the last
\r
99 > >>> modification for each individual message/max of all messages in a
\r
100 > >>> thread, similar to what Thomas Jost's patch did long ago.)
\r
102 > >>> [1] id:1406859003-11561-1-git-send-email-amdragon@mit.edu
\r
104 > >> this should allow me to do what I wish to accomplish. The message
\r
105 > >> deletion is still a problem though, I can see two options at the
\r
110 > > While exploring the possibility of syncing maildir/X-keywords with tags
\r
111 > > I had some thoughts about lastmod and message modification:
\r
113 > > As briefly discussed on #notmuch, I noticed that it seems that 'notmuch
\r
114 > > new' does not detect that a message source has been changed, unless the
\r
115 > > file is also re-named.
\r
117 > > This means that for instance if the X-Keywords fields have been updated
\r
118 > > in a message (from GMail with offlineimap, synclabels =3D yes) the last=
\r
120 > > field will remain unchanged, and a source modification will be
\r
121 > > undetectable to a client program using this value.
\r
123 > > Would it not make sense that if a message has a more recent mtime than
\r
124 > > at index time it is re-indexed?
\r
126 > This has the potential to make notmuch new substantially more expensive.
\r
127 > Currently, if there are no changes, it only has to stat each directory
\r
128 > in your maildir (in fact, some restructuring of new would let us
\r
129 > eliminate almost all database access during a no-op notmuch new as
\r
130 > well). Checking for changes to individual messages would require
\r
131 > stat'ing every single message file as well as accessing the database to
\r
132 > check the paths and mtimes of every message, increasing the number of
\r
133 > stat calls and disk accesses by several orders of magnitude.
\r
135 > It may be that this is fast enough that it's okay, but it would be good
\r
136 > to gather some evidence first. That includes hot and cold caches, and
\r
137 > maildir over NFS.
\r
139 > With respect to X-Keywords specifically, note that it's a fairly basic
\r
140 > design decision that notmuch never modifies message files. This gives
\r
141 > us strong robustness guarantees we would be loathe to part with.
\r
143 > It has puzzled me ever since offlineimap added X-Keywords why they
\r
144 > didn't just translate these keywords into folders and create hard links
\r
145 > of message files. Anything could interact smoothly with that.
\r
147 The information follows the message file. But, yeah, working directly on
\r
148 the message source is hairy. Anyway, email is as mess in general anyway. I
\r
149 consider it user-input.
\r
152 > > Also, for the lastmod branch I would wish for a notmuch_message_touch()
\r
153 > > method where the lastmod time is updated to the last. As well as a
\r
154 > > notmuch_database_reindex_message () - possibly defined/documented
\r
155 > > behaviour for notmuch_database_add_message () when the filename is
\r
156 > > already added (in which case I would expect notmuch to re-index the
\r
159 > What's the use case for these?
\r
161 If you make a change to the message source and want it to be reindexed.
\r
162 Say, edited a draft or changed a header field. I am not asking that notmuch
\r
163 modifies the message source.
\r
165 For _touch, if without making an actual change to the message you wish to
\r
166 indicate that it has been updated or synced at the current time. For
\r
167 instance after an reindex that did not make any actual change. Perhaps not
\r
168 strictly necessary.
\r
172 --001a11c35a9c71cb080503b613b8
\r
173 Content-Type: text/html; charset=UTF-8
\r
174 Content-Transfer-Encoding: quoted-printable
\r
176 <p dir=3D"ltr"><br>
\r
177 22. sep. 2014 17:40 skrev "Austin Clements" <<a href=3D"mailto=
\r
178 :aclements@csail.mit.edu">aclements@csail.mit.edu</a>> f=C3=B8lgende:<br=
\r
181 > On Mon, 22 Sep 2014, Gaute Hope <<a href=3D"mailto:eg@gaute.vetsj.c=
\r
182 om">eg@gaute.vetsj.com</a>> wrote:<br>
\r
183 > > Excerpts from Gaute Hope's message of August 6, 2014 10:29:<b=
\r
185 > >> Austin Clements <<a href=3D"mailto:amdragon@MIT.EDU">amdra=
\r
186 gon@MIT.EDU</a>> wrote on Fri, 01 Aug 2014 14:55:05 -0400:<br>
\r
187 > >>> I have a prototype implementation of message modification=
\r
189 > >>> lastmod-v1 branch at<br>
\r
190 > >>><br>
\r
191 > >>>=C2=A0 =C2=A0<a href=3D"https://github.com/aclements/notmu=
\r
192 ch/tree/lastmod-v1">https://github.com/aclements/notmuch/tree/lastmod-v1</a=
\r
194 > >>><br>
\r
195 > >>> It builds on my database features series that's curre=
\r
197 > >>> review [1].<br>
\r
198 > >>><br>
\r
199 > >>> The series uses a monotonic revision number, rather than =
\r
201 > >>> time, for reasons related to Xapian's concurrent cont=
\r
202 rol and detailed<br>
\r
203 > >>> in the main commit's commit message.=C2=A0 The implem=
\r
204 entation isn't quite<br>
\r
205 > >>> useful from the CLI yet because I haven't added any w=
\r
206 ay to query the<br>
\r
207 > >>> database's current revision number.=C2=A0 (I'm st=
\r
208 ill thinking about how I<br>
\r
209 > >>> want to do this, since search/show don't have a good =
\r
211 > >>> "additional" information right now.=C2=A0 I mig=
\r
212 ht just add the last<br>
\r
213 > >>> modification for each individual message/max of all messa=
\r
215 > >>> thread, similar to what Thomas Jost's patch did long =
\r
217 > >>><br>
\r
218 > >>> [1] <a href=3D"mailto:id%3A1406859003-11561-1-git-send-em=
\r
219 ail-amdragon@mit.edu">id:1406859003-11561-1-git-send-email-amdragon@mit.edu=
\r
222 > >> this should allow me to do what I wish to accomplish. The mes=
\r
224 > >> deletion is still a problem though, I can see two options at =
\r
227 > > Hi list,<br>
\r
229 > > While exploring the possibility of syncing maildir/X-keywords wit=
\r
231 > > I had some thoughts about lastmod and message modification:<br>
\r
233 > > As briefly discussed on #notmuch, I noticed that it seems that &#=
\r
235 > > new' does not detect that a message source has been changed, =
\r
237 > > file is also re-named.<br>
\r
239 > > This means that for instance if the X-Keywords fields have been u=
\r
241 > > in a message (from GMail with offlineimap, synclabels =3D yes) th=
\r
243 > > field will remain unchanged, and a source modification will be<br=
\r
245 > > undetectable to a client program using this value.<br>
\r
247 > > Would it not make sense that if a message has a more recent mtime=
\r
249 > > at index time it is re-indexed?<br>
\r
251 > This has the potential to make notmuch new substantially more expensiv=
\r
253 > Currently, if there are no changes, it only has to stat each directory=
\r
255 > in your maildir (in fact, some restructuring of new would let us<br>
\r
256 > eliminate almost all database access during a no-op notmuch new as<br>
\r
257 > well).=C2=A0 Checking for changes to individual messages would require=
\r
259 > stat'ing every single message file as well as accessing the databa=
\r
261 > check the paths and mtimes of every message, increasing the number of<=
\r
263 > stat calls and disk accesses by several orders of magnitude.<br>
\r
265 > It may be that this is fast enough that it's okay, but it would be=
\r
267 > to gather some evidence first.=C2=A0 That includes hot and cold caches=
\r
269 > maildir over NFS.<br>
\r
271 > With respect to X-Keywords specifically, note that it's a fairly b=
\r
273 > design decision that notmuch never modifies message files.=C2=A0 This =
\r
275 > us strong robustness guarantees we would be loathe to part with.<br>
\r
277 > It has puzzled me ever since offlineimap added X-Keywords why they<br>
\r
278 > didn't just translate these keywords into folders and create hard =
\r
280 > of message files.=C2=A0 Anything could interact smoothly with that.</p=
\r
282 <p dir=3D"ltr">The information follows the message file. But, yeah, working=
\r
283 directly on the message source is hairy. Anyway, email is as mess in gener=
\r
284 al anyway. I consider it user-input. </p>
\r
285 <p dir=3D"ltr">><br>
\r
286 > > Also, for the lastmod branch I would wish for a notmuch_message_t=
\r
288 > > method where the lastmod time is updated to the last. As well as =
\r
290 > > notmuch_database_reindex_message () - possibly defined/documented=
\r
292 > > behaviour for notmuch_database_add_message () when the filename i=
\r
294 > > already added (in which case I would expect notmuch to re-index t=
\r
296 > > message).<br>
\r
298 > What's the use case for these?</p>
\r
299 <p dir=3D"ltr">If you make a change to the message source and want it to be=
\r
300 reindexed. Say, edited a draft or changed a header field. I am not asking =
\r
301 that notmuch modifies the message source. </p>
\r
302 <p dir=3D"ltr">For _touch, if without making an actual change to the messag=
\r
303 e you wish to indicate that it has been updated or synced at the current ti=
\r
304 me. For instance after an reindex that did not make any actual change. Perh=
\r
305 aps not strictly necessary. </p>
\r
306 <p dir=3D"ltr">Cheers, Gaute </p>
\r
308 --001a11c35a9c71cb080503b613b8--
\r
projects / notmuch-archives.git / blob