From: David Mazieres Date: Mon, 28 Apr 2014 05:29:06 +0000 (+1700) Subject: Re: github mirror X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=d4b9e9ed44931b63ade35078b702f5858c98aa6f;p=notmuch-archives.git Re: github mirror --- diff --git a/10/6100aa1c2822fdba51f5f37f0276c04e7420b0 b/10/6100aa1c2822fdba51f5f37f0276c04e7420b0 new file mode 100644 index 000000000..bb986457a --- /dev/null +++ b/10/6100aa1c2822fdba51f5f37f0276c04e7420b0 @@ -0,0 +1,97 @@ +Return-Path: + +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 26828431FBD + for ; Sun, 27 Apr 2014 22:29:19 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id jhHrUF6Lf8Ay for ; + Sun, 27 Apr 2014 22:29:13 -0700 (PDT) +Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id A3621431FBC + for ; Sun, 27 Apr 2014 22:29:13 -0700 (PDT) +Received: from market.scs.stanford.edu (localhost.scs.stanford.edu + [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id + s3S5T8N1013208; Sun, 27 Apr 2014 22:29:08 -0700 (PDT) +Received: (from dm@localhost) + by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3S5T7mq003692; + Sun, 27 Apr 2014 22:29:07 -0700 (PDT) +X-Authentication-Warning: market.scs.stanford.edu: dm set sender to + return-kzv2e2wdjizdjfrw4yfxqz2gpa@ta.scs.stanford.edu using -f +From: David Mazieres +To: Austin Clements , Sam Halliday +Subject: Re: github mirror +In-Reply-To: <20140427223717.GQ25817@mit.edu> +References: <87bnvn111h.fsf@Samskara.home> <20140427223717.GQ25817@mit.edu> +Date: Sun, 27 Apr 2014 22:29:06 -0700 +Message-ID: <87y4yq9g4d.fsf@ta.scs.stanford.edu> +MIME-Version: 1.0 +Content-Type: text/plain +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +Reply-To: David Mazieres expires 2014-07-26 PDT + +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 28 Apr 2014 05:29:20 -0000 + +Austin Clements 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