35/c9195a17fba79293dee358fdb12cea764615fc

   1 Return-Path:\r
   2  <return-hrv8eihpgeb84a37siqwh9vg2i@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 2ADF3431FBD\r
   7         for <notmuch@notmuchmail.org>; Thu, 10 Apr 2014 08:32:28 -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 KbDkTKtL8psJ for <notmuch@notmuchmail.org>;\r
  17         Thu, 10 Apr 2014 08:32:21 -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 136E8431FBC\r
  22         for <notmuch@notmuchmail.org>; Thu, 10 Apr 2014 08:32:20 -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  s3AFV4Ia005872;        Thu, 10 Apr 2014 08:31:04 -0700 (PDT)\r
  26 Received: (from dm@localhost)\r
  27         by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3AFV49m008022;\r
  28         Thu, 10 Apr 2014 08:31:04 -0700 (PDT)\r
  29 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  30         return-hrv8eihpgeb84a37siqwh9vg2i@ta.scs.stanford.edu using -f\r
  31 From: dm-list-email-notmuch@scs.stanford.edu\r
  32 To: Gaute Hope <eg@gaute.vetsj.com>\r
  33 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
  34         changed on disk\r
  35 In-Reply-To: <1397140962-sup-6514@qwerzila>\r
  36 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  37         <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
  38 Date: Thu, 10 Apr 2014 08:31:04 -0700\r
  39 Message-ID: <87wqexnqvb.fsf@ta.scs.stanford.edu>\r
  40 MIME-Version: 1.0\r
  41 Content-Type: text/plain\r
  42 Cc: notmuch <notmuch@notmuchmail.org>\r
  43 X-BeenThere: notmuch@notmuchmail.org\r
  44 X-Mailman-Version: 2.1.13\r
  45 Precedence: list\r
  46 Reply-To: David Mazieres expires 2014-07-09 PDT\r
  47         <mazieres-gzp7rfravpipmg73ew8cs6n6t6@temporary-address.scs.stanford.edu>\r
  48 List-Id: "Use and development of the notmuch mail system."\r
  49         <notmuch.notmuchmail.org>\r
  50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  53 List-Post: <mailto:notmuch@notmuchmail.org>\r
  54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  57 X-List-Received-Date: Thu, 10 Apr 2014 15:32:28 -0000\r
  58 \r
  59 Gaute Hope <eg@gaute.vetsj.com> writes:\r
  60 \r
  61 >> A better approach would be to add a new "modtime" xapian value that is\r
  62 >> updated whenever the tags or any other terms (such as XFDIRENTRY) are\r
  63 >> added to or deleted from a docid.  If it's a Xapian value, rather than a\r
  64 >> term, then modtime will be queriable just like date, allowing multiple\r
  65 >> applications to query all docids modified since the last time they ran.\r
  66 >>\r
  67 >> [... snip]\r
  68 >\r
  69 > This could also solve it, and probably have more uses. I don't quite see\r
  70 > how the opposite problem (for my use case) can be solved by this without\r
  71 > using a 'localchange' tag. This is to sync tag to maildir sync, when a\r
  72 > new tag has been added (by e.g. a user interaction in a client) it needs\r
  73 > to be copied to the maildir, if it is not done in the same go a\r
  74 > different application won't know whether the change was local or remote.\r
  75 > How did you solve this?\r
  76 \r
  77 Why don't you just set maildir.synchronize_flags=true?  When I\r
  78 synchronize mail across machines, I start by concurrently running\r
  79 "notmuch new" on both the local and remote machines, which picks up all\r
  80 the changed maildir flags.  Then I synchronize the mail and the tags\r
  81 between the two maildirs.  If maildir.synchronize=true, then atomically\r
  82 with setting the new tags I call notmuch_message_tags_to_maildir_flags()\r
  83 to sync the new tags to the maildir.\r
  84 \r
  85 The maildir flags question seems kind of independent of what we are\r
  86 talking about, which is just having an incremental way of examining the\r
  87 database.  Right now, I have to scan everything to find tags that have\r
  88 changed since the last synchronization event.  If I had modtime (or\r
  89 really it should be called "ctime", like inode change time), then I\r
  90 could look at only the few messages that changed, and it would probably\r
  91 shave 250msec off polling new mail for a 100,000-message maildir.\r
  92 \r
  93 Note you can't use the file system ctime/mtime because the file system\r
  94 may have changed since the last time you ran notmuch new.\r
  95 \r
  96 > I would suggest using a Xapian- or Index-time which gets a tick\r
  97 > everytime a modification is made to the index.\r
  98 \r
  99 Exactly.  It could be a tick, or just the current time of day if your\r
 100 clock does not go backwards.  (I'd be willing to do a full scan if the\r
 101 clock ever goes backwards.)  The advantage of time is that you don't\r
 102 have to synchronously update some counter.\r
 103 \r
 104 > Atomic operations could operate on the same time in case this\r
 105 > distinction turns out to be useful. Perhaps something like this\r
 106 > already exists in Xapian?\r
 107 \r
 108 I don't think it's important for atomic operations to have the same\r
 109 timestamp.  All that's important is that you be able to diff the\r
 110 database between the last time you scanned it.\r
 111 \r
 112 > This way clock skew, clock resolution (lots of operations happening in\r
 113 > the same second, msec or nanosec) problems won't be an issue. The crux\r
 114 > will be to make sure all write-operations trigger a tick on the\r
 115 > indextime.\r
 116 \r
 117 Clock skew is not really an issue.  It takes years to amass hundreds of\r
 118 thousands of email messages.  So adding 5 minutes of slop is not a big\r
 119 deal--you'll just scan a few messages needlessly.\r
 120 \r
 121 Making sure the write-operations update the time should be easy.  Most\r
 122 or all of the changes are probably funneled through\r
 123 _notmuch_message_sync.  Worst case, there are only 9 places in the\r
 124 source code that make use of a Xapian:WritableDatabase, so I'm pretty\r
 125 confident total changes wouldn't be much more than 50 lines of code.\r
 126 \r
 127 I would do it myself if there were any kind of indication that such a\r
 128 change could be upstreamed.  I brought this up in January, 2011, and\r
 129 didn't get a huge amount of interest in the ctime idea.  But I was also\r
 130 a lot less focused on what I needed.  Now that I have a working\r
 131 distributed setup and am actually using notmuch for my mail, I have a\r
 132 much better understanding of what is needed.\r
 133 \r
 134 David\r