From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id BE530431FC3 for ; Mon, 1 Mar 2010 09:19:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_40=-0.185] autolearn=ham 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 gl2bcCT+wars for ; Mon, 1 Mar 2010 09:19:07 -0800 (PST) Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36]) by olra.theworths.org (Postfix) with ESMTP id C0A0E431FBD for ; Mon, 1 Mar 2010 09:19:06 -0800 (PST) Received: from localhost (unknown [192.168.200.4]) by max.feld.cvut.cz (Postfix) with ESMTP id EDE4B19F33BC; Mon, 1 Mar 2010 18:18:57 +0100 (CET) X-Virus-Scanned: IMAP AMAVIS Received: from max.feld.cvut.cz ([192.168.200.1]) by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new, port 10044) with ESMTP id yNfhRYBOTVyJ; Mon, 1 Mar 2010 18:18:56 +0100 (CET) Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34]) by max.feld.cvut.cz (Postfix) with ESMTP id A2F7B19F33B8; Mon, 1 Mar 2010 18:18:56 +0100 (CET) Received: from steelpick.localdomain (k335-30.felk.cvut.cz [147.32.86.30]) (Authenticated sender: sojkam1) by imap.feld.cvut.cz (Postfix) with ESMTPSA id 7A349FA003; Mon, 1 Mar 2010 18:18:56 +0100 (CET) Received: from wsh by steelpick.localdomain with local (Exim 4.71) (envelope-from ) id 1Nm9Gi-0005Ax-CD; Mon, 01 Mar 2010 18:18:56 +0100 From: Michal Sojka To: Ben Gamari , notmuch In-Reply-To: <1267459947-sup-6640@ben-laptop> References: <87pr57jvkz.fsf@SSpaeth.de> <87wry2wl7p.fsf@yoom.home.cworth.org> <87ljecmnbd.fsf@steelpick.localdomain> <1267459947-sup-6640@ben-laptop> Date: Mon, 01 Mar 2010 18:18:55 +0100 Message-ID: <87bpf82c5c.fsf@steelpick.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Introducing notmuchsync X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list 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, 01 Mar 2010 17:19:07 -0000 On Mon, 01 Mar 2010 11:27:07 -0500, Ben Gamari wrote: > > 2. get the list of new mails which need to be indexed > > (current notmuch does recursive file traversal, for git-based store > > it will be something like system("git diff-tree --name-status ...") > > > Is this really necessary? Another option (which I believe has been > mentioned here in the past) is to simply pass notmuch new a list of > message "paths" to add (although I'm not sure if many mail delivery > programs give you that sort of information). This could also be possible, but now, you say "notmuch new" and notmuch itself figure out what to index. If passing notmuch a list on files to index will be the only supported way, it might be hard for new users to start with notmuch. A nice thing on notmuch is that it can be used almost without any configuration. > How do you propose that the backends keep track of what mail has been > indexed? For example by using Xapian metadata: notmuch->xapian_db->set_metadata ("git-head", sha1); > > Now, if we have this, it would be very easy to add support for > > Maildir-based mail-store. The implementation of the first two methods > > would be the same as what is currently in notmuch and the third method > > would rename files in mailstore if certain tags (such as unread) are > > added or removed. In case of rename, notmuch database would be > > immediately updated to reflect the change. > > > The interface here seems a little vague. How would the backend notify > notmuch that the filename has changed? notmuch new The idea is that tags changed by notmuch are stored immediately (and database is updated accordingly), whereas when the mail store is changed by an external tool, you must explicitly ask notmuch to notice that. > > So to summarize, I think there should be an abstract layer for > > handling different types of mail-store. I can see at least three > > possible implementations of this abstract interface: 1) immutable > > mail-store (as currently implemented in notmuch) 2) Maildir-based > > mail-store for limited synchronization with other Maildir tools and > > 3) git-based mail-store for full synchronization. > > Don't forget mbox. It seems like it would be pretty trivial to > implement (although I'm not sure what performance would look like). I personally do not use mboxes, so I'm not interested in them. > > I've already started working on this, but I'm still in the state where I > > mainly study how notmuch works in order not to break its current > > functionality. > > With all of this infrastructure, it seems like it wouldn't be too > difficult to support messages from multiple backends in a single index. > Not sure if people would be interested enough to warrant the added > complexity though. I'm currently not interested in such a functionality, but we can add it later if there is a need. Bye Michal