-Think about this race condition:
-
- A client executes "notmuch search"
- Then executes "notmuch show" on a thread
- While user is reading, new mail is added to database for the thread
- Client asks for the thread to be archived.
-
- The bug here is that email that was never read will be
- archived. That's bad. With the command set above, the user can
- avoid the problem by just not running "notmuch new" while reading
- mail, but the same problems exists with the API. One possible
- solution would be to store an additional timestamp with each mail
- document for the time it was added to the database. Then searches
- could return a timestamp, and the client could pass that same
- timestamp back to the archive command to not modify any messages
- with a timestamp newer than what's passed.
+Add support for the user to specify custom headers to be indexed.
+
+Add support for automatic tagging of new messages based on particular
+search criteria, (likely using an InMemory database for the new
+messages).
+
+Fix notmuch.c to call add_timestamp/get_timestampt with path names
+relative to the database path. (Otherwise, moving the database to a
+new directory will result in notmuch creating new timestamp documents
+and leaving stale ones behind.)
+
+Fix notmuch.c to use a DIR prefix for directory timestamps, (the idea
+being that it can then add other non-directory timestamps such as for
+noting how far back in the past mail has been indexed, and whether it
+needs to re-tag messages based on a theoretical "auto-tags"
+configuration file).
+
+Audit everything for dealing with out-of-memory (and drop xutil.c).
+
+Write a test suite.
+
+Achieve 100% test coverage with the test suite.