Re: [PATCH] Add configurable changed tag to messages that have been changed on disk
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add configurable changed tag to messages that have been changed on disk
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