debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-29 06:04:11 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

TODO: More notes on archive-thread and race conditions.

Browse source 
Interstingly, it's our simple "notmuch" client that's going to be the
most difficult to fix. There's just not as much information preserved
in the textual representation from "notmuch search" as there is in the
objects returned from notmuch_query_search_threads.
This commit is contained in:
Carl Worth 2009-10-27 10:19:46 -07:00
parent c690420076
commit f2bcc256fb
1 changed files with 23 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
TODO
View file

@ -15,11 +15,26 @@ Think about this race condition:
Client asks for the thread to be archived. Client asks for the thread to be archived.
The bug here is that email that was never read will be The bug here is that email that was never read will be
archived. That's bad. With the command set above, the user can archived. That's bad. The fix for the above is for the client to
avoid the problem by just not running "notmuch new" while reading archive the individual messages already retrieved and shown, not
mail, but the same problems exists with the API. One possible the thread. (And in fact, we don't even have functions for removing
solution would be to store an additional timestamp with each mail tags on threads.)
document for the time it was added to the database. Then searches
could return a timestamp, and the client could pass that same But this one is harder to fix:
timestamp back to the archive command to not modify any messages
with a timestamp newer than what's passed. 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).