debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-12-22 17:34:54 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

TODO: Remove a couple of since-completed items.

Browse source 
"notmuch tag" is implemented now and seems to work great (and fast).

As for the race condition, as noted in the description we're removing
it's not exposed directly in the API, but only in a client that
allows for looping over search results and removing the inbox tag
from all of them. But then, that's exactly what the "notmuch tag"
command does. So, as discussed, we've now documented that command
to highlight the issue. Problem resolved, (as well as we can).
This commit is contained in:
Carl Worth 2009-10-28 01:46:24 -07:00
parent 19ec20192c
commit f8a14b698f
1 changed files with 0 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
TODO
View file

@ -1,6 +1,3 @@
Write a "notmuch tag" command to add/remove tags from messages
matching a search query.
Rename notmuch_thread_results_t and notmuch_message_results_t to
notmuch_threads_t and notmuch_messages_t respectively.
@ -18,35 +15,3 @@ Audit everything for dealing with out-of-memory (and drop xutil.c).
Write a test suite.
Achieve 100% test coverage with the test suite.
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. The fix for the above is for the client to
archive the individual messages already retrieved and shown, not
the thread. (And in fact, we don't even have functions for removing
tags on threads.)
But this one is harder to fix:
A client executes "notmuch search"
While user is reading, new mail is added to database for the thread
Client asks for a thread to be archived.
To support this operation, (archiving a thread without even seeing
the individual messages), we might need to provide a command to
archive a thread as a whole. The problem is actually easy to fix
for a persistent client. It can onto the originally retrieved
thread objects which can hold onto the originally retrieved
messages. So archiving those thread objects, (and not newly created
thread objects), will be safe.
It's harder to fix the non-persistent "notmuch" client. One
approach is to simply tell the user to not run "notmuch new"
between reading the results of "notmuch search" and executing
"notmuch archive-thread" (or whatever we name it).