github mirror

[David Mazieres]

Austin Clements <amdragon at MIT.EDU> writes:

> As for storing this information directly in messages, in general, the
> notmuch community is opposed to modifying messages.  This causes many
> problems, and immutable messages are more robust and simplify so many
> things.  IMAP assumes messages are immutable.  Maildir assumes
> messages are immutable.  Notmuch new would get dramatically slower if
> it had to check for messages modifications.  What do you do if you
> change a tag and there are multiple copies of a message?  What do you
> do if there are multiple copies and they disagree about the tags?  How
> do you atomically update the tags stored in a message?  From an
> engineering standpoint, it's much better to avoid mutable messages.

The speed penalty would be very minor in the common case.  Muchsync
scans directories (since it has to scan file contents) and the cost to
compute SHA-1 hashes of modified files is under 50 msec or something in
the common case.  Extracting tags would be even cheaper.  The reason is
that A) you only need to scan modified directories, and B) you don't
need to open the file unless the inode, mtime, or size has changed.
Originally I was going to implement an optimization to detect renamed
files and avoid computing SHA-1 again (for the case where maildir flags
have changed), but in the end this wasn't even worth it because the cost
is so small.

That said, I agree that the complexity of altering files is not worth
it.  Especially since most imap servers will not know about this.  Also,
the question of what do you do with duplicate message IDs (which is
effectively what you have when the tags disagree) is a more general
problem still needing a solution, and would be exacerbated by embedding
important information like tags in the message.

Really what you want is an imap server built on top of the notmuch
library.  That way you could use notmuch from your desktop and then use
imap from your phone, and everything would stay perfectly in sync.
Implementing such a server wouldn't be that hard, but it would help if
notmuch made the _notmuch_message_get_doc_id and
_notmuch_directory_get_document_id functions semi-public.  Then the imap
server could just use docids as uids.  (Plus then muchsync wouldn't have
to go through gross contortions to get docids information...)

David