--- /dev/null
+Return-Path: <eg@gaute.vetsj.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 21210431FAF\r
+ for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 23:57:26 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.699\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
+ tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id cfyHJiruYHlt for <notmuch@notmuchmail.org>;\r
+ Mon, 22 Sep 2014 23:57:09 -0700 (PDT)\r
+Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com\r
+ [209.85.192.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 89EF1431FAE\r
+ for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 23:57:09 -0700 (PDT)\r
+Received: by mail-qg0-f44.google.com with SMTP id f51so4177176qge.3\r
+ for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 23:57:08 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:mime-version:in-reply-to:references:date\r
+ :message-id:subject:from:to:cc:content-type;\r
+ bh=bqs7RpSw4T/jZaRqde4Q+ZnDMqzMYWouvanyODghIHQ=;\r
+ b=SH3XN7UZtLXTHZGzPyrja8W79mdxkdQxUk1GdKEPkMS5BzJxNpfr8jqw+QDhm65L3j\r
+ LdesHP4GnJZ5u0IH2y+0QV6Nq0E9jl4btob55FNuZ7WrN7m2/16WGYcNAFe0DgHmUxo4\r
+ gQyceNWbB7VL5+JwAYjK+uQfRC2pcrA405wdcFBuD6Dz3tirDDnNt+YkKJ6yoAzBJL9t\r
+ wa5v+NF0tZOCfXiEJVSQeI7xXQJWMydXRx+1PJp6PioCVb/73ZSZ/1jj+Y06lX5d9wDO\r
+ rR1/AgsHhapCun/IqB9epszmzgrkDFvPmLvq6DWhzP6AC16+oPjtclKSVVupMfl4MEPP\r
+ UDlA==\r
+X-Gm-Message-State:\r
+ ALoCoQmbhPmdvmHEI1JoECLSQ1OqSgnlGyjHpraZdrZV5u3ipXaKdTmkXdQxilJlP2MBE7Mtu0Js\r
+MIME-Version: 1.0\r
+X-Received: by 10.224.46.6 with SMTP id h6mr29733002qaf.45.1411455428701; Mon,\r
+ 22 Sep 2014 23:57:08 -0700 (PDT)\r
+Received: by 10.96.174.104 with HTTP; Mon, 22 Sep 2014 23:57:08 -0700 (PDT)\r
+Received: by 10.96.174.104 with HTTP; Mon, 22 Sep 2014 23:57:08 -0700 (PDT)\r
+In-Reply-To: <87k34vackm.fsf@drake.dyndns.org>\r
+References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
+ <87fviiiuzn.fsf@maritornes.cs.unb.ca>\r
+ <CABKe4Mv6p77i5dBT9BV41hxmtrE4UPLR3NjZfpLuZDoE1KWYyA@mail.gmail.com>\r
+ <20140801185505.GS13893@mit.edu>\r
+ <1407313144-astroid-0-vyhth1tcrd-3835@strange>\r
+ <1411386960-astroid-2-k1e726ut3f-2518@strange>\r
+ <87k34vackm.fsf@drake.dyndns.org>\r
+Date: Tue, 23 Sep 2014 08:57:08 +0200\r
+Message-ID:\r
+ <CABKe4MsXuOz2Amrw6qRxohGe7qujA3xuNFG=ENYAho9gnk72pA@mail.gmail.com>\r
+Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
+ changed on disk\r
+From: Gaute Hope <eg@gaute.vetsj.com>\r
+To: Austin Clements <aclements@csail.mit.edu>\r
+Content-Type: multipart/alternative; boundary=001a11c35a9c71cb080503b613b8\r
+Cc: notmuch <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 23 Sep 2014 06:57:26 -0000\r
+\r
+--001a11c35a9c71cb080503b613b8\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+22. sep. 2014 17:40 skrev "Austin Clements" <aclements@csail.mit.edu>\r
+f=C3=B8lgende:\r
+>\r
+> On Mon, 22 Sep 2014, Gaute Hope <eg@gaute.vetsj.com> wrote:\r
+> > Excerpts from Gaute Hope's message of August 6, 2014 10:29:\r
+> >> Austin Clements <amdragon@MIT.EDU> wrote on Fri, 01 Aug 2014 14:55:05\r
+-0400:\r
+> >>> I have a prototype implementation of message modification times on my\r
+> >>> lastmod-v1 branch at\r
+> >>>\r
+> >>> https://github.com/aclements/notmuch/tree/lastmod-v1\r
+> >>>\r
+> >>> It builds on my database features series that's currently awaiting\r
+> >>> review [1].\r
+> >>>\r
+> >>> The series uses a monotonic revision number, rather than wall-clock\r
+> >>> time, for reasons related to Xapian's concurrent control and detailed\r
+> >>> in the main commit's commit message. The implementation isn't quite\r
+> >>> useful from the CLI yet because I haven't added any way to query the\r
+> >>> database's current revision number. (I'm still thinking about how I\r
+> >>> want to do this, since search/show don't have a good way to deliver\r
+> >>> "additional" information right now. I might just add the last\r
+> >>> modification for each individual message/max of all messages in a\r
+> >>> thread, similar to what Thomas Jost's patch did long ago.)\r
+> >>>\r
+> >>> [1] id:1406859003-11561-1-git-send-email-amdragon@mit.edu\r
+> >\r
+> >> this should allow me to do what I wish to accomplish. The message\r
+> >> deletion is still a problem though, I can see two options at the\r
+moment:\r
+> >\r
+> > Hi list,\r
+> >\r
+> > While exploring the possibility of syncing maildir/X-keywords with tags\r
+> > I had some thoughts about lastmod and message modification:\r
+> >\r
+> > As briefly discussed on #notmuch, I noticed that it seems that 'notmuch\r
+> > new' does not detect that a message source has been changed, unless the\r
+> > file is also re-named.\r
+> >\r
+> > This means that for instance if the X-Keywords fields have been updated\r
+> > in a message (from GMail with offlineimap, synclabels =3D yes) the last=\r
+mod\r
+> > field will remain unchanged, and a source modification will be\r
+> > undetectable to a client program using this value.\r
+> >\r
+> > Would it not make sense that if a message has a more recent mtime than\r
+> > at index time it is re-indexed?\r
+>\r
+> This has the potential to make notmuch new substantially more expensive.\r
+> Currently, if there are no changes, it only has to stat each directory\r
+> in your maildir (in fact, some restructuring of new would let us\r
+> eliminate almost all database access during a no-op notmuch new as\r
+> well). Checking for changes to individual messages would require\r
+> stat'ing every single message file as well as accessing the database to\r
+> check the paths and mtimes of every message, increasing the number of\r
+> stat calls and disk accesses by several orders of magnitude.\r
+>\r
+> It may be that this is fast enough that it's okay, but it would be good\r
+> to gather some evidence first. That includes hot and cold caches, and\r
+> maildir over NFS.\r
+>\r
+> With respect to X-Keywords specifically, note that it's a fairly basic\r
+> design decision that notmuch never modifies message files. This gives\r
+> us strong robustness guarantees we would be loathe to part with.\r
+>\r
+> It has puzzled me ever since offlineimap added X-Keywords why they\r
+> didn't just translate these keywords into folders and create hard links\r
+> of message files. Anything could interact smoothly with that.\r
+\r
+The information follows the message file. But, yeah, working directly on\r
+the message source is hairy. Anyway, email is as mess in general anyway. I\r
+consider it user-input.\r
+\r
+>\r
+> > Also, for the lastmod branch I would wish for a notmuch_message_touch()\r
+> > method where the lastmod time is updated to the last. As well as a\r
+> > notmuch_database_reindex_message () - possibly defined/documented\r
+> > behaviour for notmuch_database_add_message () when the filename is\r
+> > already added (in which case I would expect notmuch to re-index the\r
+> > message).\r
+>\r
+> What's the use case for these?\r
+\r
+If you make a change to the message source and want it to be reindexed.\r
+Say, edited a draft or changed a header field. I am not asking that notmuch\r
+modifies the message source.\r
+\r
+For _touch, if without making an actual change to the message you wish to\r
+indicate that it has been updated or synced at the current time. For\r
+instance after an reindex that did not make any actual change. Perhaps not\r
+strictly necessary.\r
+\r
+Cheers, Gaute\r
+\r
+--001a11c35a9c71cb080503b613b8\r
+Content-Type: text/html; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+<p dir=3D"ltr"><br>\r
+22. sep. 2014 17:40 skrev "Austin Clements" <<a href=3D"mailto=\r
+:aclements@csail.mit.edu">aclements@csail.mit.edu</a>> f=C3=B8lgende:<br=\r
+>\r
+><br>\r
+> On Mon, 22 Sep 2014, Gaute Hope <<a href=3D"mailto:eg@gaute.vetsj.c=\r
+om">eg@gaute.vetsj.com</a>> wrote:<br>\r
+> > Excerpts from Gaute Hope's message of August 6, 2014 10:29:<b=\r
+r>\r
+> >> Austin Clements <<a href=3D"mailto:amdragon@MIT.EDU">amdra=\r
+gon@MIT.EDU</a>> wrote on Fri, 01 Aug 2014 14:55:05 -0400:<br>\r
+> >>> I have a prototype implementation of message modification=\r
+ times on my<br>\r
+> >>> lastmod-v1 branch at<br>\r
+> >>><br>\r
+> >>>=C2=A0 =C2=A0<a href=3D"https://github.com/aclements/notmu=\r
+ch/tree/lastmod-v1">https://github.com/aclements/notmuch/tree/lastmod-v1</a=\r
+><br>\r
+> >>><br>\r
+> >>> It builds on my database features series that's curre=\r
+ntly awaiting<br>\r
+> >>> review [1].<br>\r
+> >>><br>\r
+> >>> The series uses a monotonic revision number, rather than =\r
+wall-clock<br>\r
+> >>> time, for reasons related to Xapian's concurrent cont=\r
+rol and detailed<br>\r
+> >>> in the main commit's commit message.=C2=A0 The implem=\r
+entation isn't quite<br>\r
+> >>> useful from the CLI yet because I haven't added any w=\r
+ay to query the<br>\r
+> >>> database's current revision number.=C2=A0 (I'm st=\r
+ill thinking about how I<br>\r
+> >>> want to do this, since search/show don't have a good =\r
+way to deliver<br>\r
+> >>> "additional" information right now.=C2=A0 I mig=\r
+ht just add the last<br>\r
+> >>> modification for each individual message/max of all messa=\r
+ges in a<br>\r
+> >>> thread, similar to what Thomas Jost's patch did long =\r
+ago.)<br>\r
+> >>><br>\r
+> >>> [1] <a href=3D"mailto:id%3A1406859003-11561-1-git-send-em=\r
+ail-amdragon@mit.edu">id:1406859003-11561-1-git-send-email-amdragon@mit.edu=\r
+</a><br>\r
+> ><br>\r
+> >> this should allow me to do what I wish to accomplish. The mes=\r
+sage<br>\r
+> >> deletion is still a problem though, I can see two options at =\r
+the moment:<br>\r
+> ><br>\r
+> > Hi list,<br>\r
+> ><br>\r
+> > While exploring the possibility of syncing maildir/X-keywords wit=\r
+h tags<br>\r
+> > I had some thoughts about lastmod and message modification:<br>\r
+> ><br>\r
+> > As briefly discussed on #notmuch, I noticed that it seems that &#=\r
+39;notmuch<br>\r
+> > new' does not detect that a message source has been changed, =\r
+unless the<br>\r
+> > file is also re-named.<br>\r
+> ><br>\r
+> > This means that for instance if the X-Keywords fields have been u=\r
+pdated<br>\r
+> > in a message (from GMail with offlineimap, synclabels =3D yes) th=\r
+e lastmod<br>\r
+> > field will remain unchanged, and a source modification will be<br=\r
+>\r
+> > undetectable to a client program using this value.<br>\r
+> ><br>\r
+> > Would it not make sense that if a message has a more recent mtime=\r
+ than<br>\r
+> > at index time it is re-indexed?<br>\r
+><br>\r
+> This has the potential to make notmuch new substantially more expensiv=\r
+e.<br>\r
+> Currently, if there are no changes, it only has to stat each directory=\r
+<br>\r
+> in your maildir (in fact, some restructuring of new would let us<br>\r
+> eliminate almost all database access during a no-op notmuch new as<br>\r
+> well).=C2=A0 Checking for changes to individual messages would require=\r
+<br>\r
+> stat'ing every single message file as well as accessing the databa=\r
+se to<br>\r
+> check the paths and mtimes of every message, increasing the number of<=\r
+br>\r
+> stat calls and disk accesses by several orders of magnitude.<br>\r
+><br>\r
+> It may be that this is fast enough that it's okay, but it would be=\r
+ good<br>\r
+> to gather some evidence first.=C2=A0 That includes hot and cold caches=\r
+, and<br>\r
+> maildir over NFS.<br>\r
+><br>\r
+> With respect to X-Keywords specifically, note that it's a fairly b=\r
+asic<br>\r
+> design decision that notmuch never modifies message files.=C2=A0 This =\r
+gives<br>\r
+> us strong robustness guarantees we would be loathe to part with.<br>\r
+><br>\r
+> It has puzzled me ever since offlineimap added X-Keywords why they<br>\r
+> didn't just translate these keywords into folders and create hard =\r
+links<br>\r
+> of message files.=C2=A0 Anything could interact smoothly with that.</p=\r
+>\r
+<p dir=3D"ltr">The information follows the message file. But, yeah, working=\r
+ directly on the message source is hairy. Anyway, email is as mess in gener=\r
+al anyway. I consider it user-input. </p>\r
+<p dir=3D"ltr">><br>\r
+> > Also, for the lastmod branch I would wish for a notmuch_message_t=\r
+ouch()<br>\r
+> > method where the lastmod time is updated to the last. As well as =\r
+a<br>\r
+> > notmuch_database_reindex_message () - possibly defined/documented=\r
+<br>\r
+> > behaviour for notmuch_database_add_message () when the filename i=\r
+s<br>\r
+> > already added (in which case I would expect notmuch to re-index t=\r
+he<br>\r
+> > message).<br>\r
+><br>\r
+> What's the use case for these?</p>\r
+<p dir=3D"ltr">If you make a change to the message source and want it to be=\r
+ reindexed. Say, edited a draft or changed a header field. I am not asking =\r
+that notmuch modifies the message source. </p>\r
+<p dir=3D"ltr">For _touch, if without making an actual change to the messag=\r
+e you wish to indicate that it has been updated or synced at the current ti=\r
+me. For instance after an reindex that did not make any actual change. Perh=\r
+aps not strictly necessary. </p>\r
+<p dir=3D"ltr">Cheers, Gaute </p>\r
+\r
+--001a11c35a9c71cb080503b613b8--\r
projects / notmuch-archives.git / commitdiff