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

[David Mazieres expires 2014-07-22 PDT]

Austin Clements <amdragon at MIT.EDU> 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