--- /dev/null
+Return-Path:\r
+ <return-kzv2e2wdjizdjfrw4yfxqz2gpa@temporary-address.scs.stanford.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 26828431FBD\r
+ for <notmuch@notmuchmail.org>; Sun, 27 Apr 2014 22:29:19 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id jhHrUF6Lf8Ay for <notmuch@notmuchmail.org>;\r
+ Sun, 27 Apr 2014 22:29:13 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id A3621431FBC\r
+ for <notmuch@notmuchmail.org>; Sun, 27 Apr 2014 22:29:13 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
+ [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
+ s3S5T8N1013208; Sun, 27 Apr 2014 22:29:08 -0700 (PDT)\r
+Received: (from dm@localhost)\r
+ by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3S5T7mq003692;\r
+ Sun, 27 Apr 2014 22:29:07 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+ return-kzv2e2wdjizdjfrw4yfxqz2gpa@ta.scs.stanford.edu using -f\r
+From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
+To: Austin Clements <amdragon@MIT.EDU>, Sam Halliday <sam.halliday@gmail.com>\r
+Subject: Re: github mirror\r
+In-Reply-To: <20140427223717.GQ25817@mit.edu>\r
+References: <87bnvn111h.fsf@Samskara.home> <20140427223717.GQ25817@mit.edu>\r
+Date: Sun, 27 Apr 2014 22:29:06 -0700\r
+Message-ID: <87y4yq9g4d.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+Reply-To: David Mazieres expires 2014-07-26 PDT\r
+ <mazieres-9846a2ffhp9rshhcawsvbt8pks@temporary-address.scs.stanford.edu>\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 28 Apr 2014 05:29:20 -0000\r
+\r
+Austin Clements <amdragon@MIT.EDU> writes:\r
+\r
+> As for storing this information directly in messages, in general, the\r
+> notmuch community is opposed to modifying messages. This causes many\r
+> problems, and immutable messages are more robust and simplify so many\r
+> things. IMAP assumes messages are immutable. Maildir assumes\r
+> messages are immutable. Notmuch new would get dramatically slower if\r
+> it had to check for messages modifications. What do you do if you\r
+> change a tag and there are multiple copies of a message? What do you\r
+> do if there are multiple copies and they disagree about the tags? How\r
+> do you atomically update the tags stored in a message? From an\r
+> engineering standpoint, it's much better to avoid mutable messages.\r
+\r
+The speed penalty would be very minor in the common case. Muchsync\r
+scans directories (since it has to scan file contents) and the cost to\r
+compute SHA-1 hashes of modified files is under 50 msec or something in\r
+the common case. Extracting tags would be even cheaper. The reason is\r
+that A) you only need to scan modified directories, and B) you don't\r
+need to open the file unless the inode, mtime, or size has changed.\r
+Originally I was going to implement an optimization to detect renamed\r
+files and avoid computing SHA-1 again (for the case where maildir flags\r
+have changed), but in the end this wasn't even worth it because the cost\r
+is so small.\r
+\r
+That said, I agree that the complexity of altering files is not worth\r
+it. Especially since most imap servers will not know about this. Also,\r
+the question of what do you do with duplicate message IDs (which is\r
+effectively what you have when the tags disagree) is a more general\r
+problem still needing a solution, and would be exacerbated by embedding\r
+important information like tags in the message.\r
+\r
+Really what you want is an imap server built on top of the notmuch\r
+library. That way you could use notmuch from your desktop and then use\r
+imap from your phone, and everything would stay perfectly in sync.\r
+Implementing such a server wouldn't be that hard, but it would help if\r
+notmuch made the _notmuch_message_get_doc_id and\r
+_notmuch_directory_get_document_id functions semi-public. Then the imap\r
+server could just use docids as uids. (Plus then muchsync wouldn't have\r
+to go through gross contortions to get docids information...)\r
+\r
+David\r