08/93a19356d6fae63e51dbb9b82673a2a49e9c6f

   1 Return-Path:\r
   2  <return-qins2mg6jwx9mkqf94wrbsevww@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6         by olra.theworths.org (Postfix) with ESMTP id 304B5431FBC\r
   7         for <notmuch@notmuchmail.org>; Sun,  6 Apr 2014 13:19:30 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.3\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
  13         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id s62A4tGVgLJO for <notmuch@notmuchmail.org>;\r
  17         Sun,  6 Apr 2014 13:19:24 -0700 (PDT)\r
  18 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 26004431FB6\r
  22         for <notmuch@notmuchmail.org>; Sun,  6 Apr 2014 13:19:24 -0700 (PDT)\r
  23 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  24  [127.0.0.1])   by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  25  s36KJLvB015571;        Sun, 6 Apr 2014 13:19:21 -0700 (PDT)\r
  26 Received: (from dm@localhost)\r
  27         by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s36KJKZv025070;\r
  28         Sun, 6 Apr 2014 13:19:20 -0700 (PDT)\r
  29 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  30         return-qins2mg6jwx9mkqf94wrbsevww@ta.scs.stanford.edu using -f\r
  31 From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
  32 To: Gaute Hope <eg@gaute.vetsj.com>, notmuch@notmuchmail.org\r
  33 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
  34         changed on disk\r
  35 In-Reply-To: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  36 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  37 Date: Sun, 06 Apr 2014 22:19:19 +0200\r
  38 Message-ID: <87wqf2gqig.fsf@ta.scs.stanford.edu>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: text/plain\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 Reply-To: David Mazieres expires 2014-07-05 CEST\r
  45         <mazieres-2vu8n5xbqk4r8zkqh82n4qgci6@temporary-address.scs.stanford.edu>\r
  46 List-Id: "Use and development of the notmuch mail system."\r
  47         <notmuch.notmuchmail.org>\r
  48 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  50 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  51 List-Post: <mailto:notmuch@notmuchmail.org>\r
  52 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  53 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  55 X-List-Received-Date: Sun, 06 Apr 2014 20:19:30 -0000\r
  56 \r
  57 Gaute Hope <eg@gaute.vetsj.com> writes:\r
  58 \r
  59 > When one of the source files for a message is changed on disk, renamed,\r
  60 > deleted or a new source file is added. A configurable changed tag is\r
  61 > is added. The tag can be configured under the option 'changed_tags' in\r
  62 > the [new] section, the default is none. Tests have been updated to\r
  63 > accept the new config option.\r
  64 >\r
  65 > notmuch-setup now asks for a changed tag after the new tags question.\r
  66 >\r
  67 > This could be useful for for example 'afew' to detect remote changes in\r
  68 > IMAP folders and update the FolderNameFilter to also add tags or remove\r
  69 > tags when a _existing_ message has been added to or removed from a\r
  70 > maildir.\r
  71 \r
  72 I think this is the wrong way to achieve such functionality, because\r
  73 then the change tag A) is expensive to remove, B) is easy to misuse\r
  74 (remember to call fsync everywhere before deleting the change tag), and\r
  75 C) can be used by only one application.\r
  76 \r
  77 A better approach would be to add a new "modtime" xapian value that is\r
  78 updated whenever the tags or any other terms (such as XFDIRENTRY) are\r
  79 added to or deleted from a docid.  If it's a Xapian value, rather than a\r
  80 term, then modtime will be queriable just like date, allowing multiple\r
  81 applications to query all docids modified since the last time they ran.\r
  82 \r
  83 I currently have multiple applications that could significantly benefit\r
  84 from such a modtime.  An obvious one is proper incremental backups with\r
  85 notmuch-dump.\r
  86 \r
  87 Another example is a tool I have that synchromizes maildirs and notmuch\r
  88 tags across machines.  With the current interface, there is no way to do\r
  89 this without scanning the entire database, because any message, even a\r
  90 very old one, may have changed tags or links.  Moreover, something like\r
  91 notmuch-dump is way, way too slow to run every time you want to check\r
  92 for new mail.  notmuch-dump costs 5-10 seconds on my 110,000-message\r
  93 maildir!  In fact, any approach the gathers tags associated with each\r
  94 individual docid is a complete non-starter, forcing me to violate\r
  95 abstraction and examine the postlists associated with each tag and\r
  96 XFDIRENTRY term.  Even my highly optimized implementation takes about\r
  97 250 msec (1400 msec on a 32-bit machine), which adds perceptible latency\r
  98 to synchronizing my clients' notmuch maildirs with my server's when I\r
  99 poll for new mail.\r
 100 \r
 101 Yet another application is something like nottoomuch-addresses, which\r
 102 currently uses an occasionally incorrect heuristic to detect new\r
 103 messages based on the Date header.\r
 104 \r
 105 Let me make a stronger statement, which is that not only are\r
 106 modification times an incredibly useful and general primitive, but lack\r
 107 of modification times is the single thing that kept me away from notmuch\r
 108 despite years of wanting to switch.  In the end, I invested months\r
 109 developing a highly-optimized change detector that efficiently diffs\r
 110 Xapian's Btrees against a mysql database with a snapshot of the same\r
 111 information.  My solution works, and I now enjoy a replicated notmuch\r
 112 setup synchronized across three machines, including offline access on my\r
 113 laptop.  But my 4,000-line C++ program might have been a 400-line shell\r
 114 script if only notmuch supported docid mod times.\r
 115 \r
 116 Also, to put this in perspective, how long does it take to remove the\r
 117 changed tags from a bunch of messages?  If it's longer than 300 msec on\r
 118 a 64-bit machine, then even with a single application you'd be better\r
 119 off using my crazy on-the-side mysql version vector scheme.\r
 120 \r
 121 David\r