Re: [PATCH] Add configurable changed tag to messages that have been changed on disk

diff --git a/e8/d954c2988ae2ad93982eb05c829f08654e6e26 b/e8/d954c2988ae2ad93982eb05c829f08654e6e26
new file mode 100644 (file)
index 0000000..1d364f5
--- /dev/null
+++ b/e8/d954c2988ae2ad93982eb05c829f08654e6e26
@@ -0,0 +1,92 @@
+Return-Path:\r
+ <return-qmnycg9wiz5cu6ip5aj3etzjes@temporary-address.scs.stanford.edu>\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 5C6E4431FC7\r
+       for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 15:40:56 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3] 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 tp7MzSqumQHg for <notmuch@notmuchmail.org>;\r
+       Wed, 23 Apr 2014 15:40:51 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 843C1431FBF\r
+       for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 15:40:51 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
+ [127.0.0.1])  by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
+ s3NMemWH017974;       Wed, 23 Apr 2014 15:40:48 -0700 (PDT)\r
+Received: (from dm@localhost)\r
+       by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3NMemIL024483;\r
+       Wed, 23 Apr 2014 15:40:48 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+       return-qmnycg9wiz5cu6ip5aj3etzjes@ta.scs.stanford.edu using -f\r
+From: David Mazieres expires 2014-07-22 PDT\r
+       <mazieres-af37krnn9d5vk6tdzeddvbf7qi@temporary-address.scs.stanford.edu>\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
+       changed on disk\r
+In-Reply-To: <20140423212843.GN25817@mit.edu>\r
+References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
+       <87wqf2gqig.fsf@ta.scs.stanford.edu>\r
+       <20140423212843.GN25817@mit.edu>\r
+Date: Wed, 23 Apr 2014 15:40:47 -0700\r
+Message-ID: <87fvl34qkw.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-Mailman-Approved-At: Thu, 24 Apr 2014 09:04:36 -0700\r
+Cc: 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: Wed, 23 Apr 2014 22:40:56 -0000\r
+\r
+Austin Clements <amdragon@MIT.EDU> writes:\r
+\r
+> I'd like to have efficient change detection, too.  In my case, I'd\r
+> like to use it to support efficient live search and show updates.  The\r
+> design I'd sketched out for that used a log rather than ctimes, and\r
+> I'm curious if you have thoughts on the relative merits and\r
+> suitability for tag sync of these approaches.\r
+\r
+Both logging ctime are very general mechanisms than can solve many\r
+problems.  For example, is there still an issue that pressing "*" in\r
+emacs notmuch-search mode can affect messages that are not visible if\r
+someone ran notmuch new in a different window?  ctimes would be one way\r
+to solve this.  (Conservatively exempt any messages that have changed\r
+since the displayed search was run.)\r
+\r
+> I'd been leaning toward logging because it can capture changes to\r
+> things that aren't represented as documents in the database, such as\r
+> thread membership.  This probably doesn't matter for synchronization,\r
+> but it makes it much easier to figure out which threads in thread\r
+> search results need to be refreshed.  A log can also capture message\r
+> deletion easily, while ctimes would require tombstones (which may be a\r
+> good idea for other reasons [1]).\r
+>\r
+> On the other hand, logging is obviously more mechanism than ctimes,\r
+> and probably requires some garbage collection story.\r
+\r
+The advantage of ctime over logging is that the interface is super\r
+simple and intuitive.  How would the interface to the log work?\r
+\r
+In terms of implementation, have you thought about leveraging the\r
+XAPIAN_MAX_CHANGESETS mechanism to produce your logs?\r
+\r
+David\r