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