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 DEBF5431FC0 for ; Sun, 24 Jan 2010 23:46:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 6paPulOmEjdQ for ; Sun, 24 Jan 2010 23:46:23 -0800 (PST) Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96]) by olra.theworths.org (Postfix) with ESMTP id A5DE4431FBC for ; Sun, 24 Jan 2010 23:46:22 -0800 (PST) Received: from lapse.rw.madduck.net (121-73-68-174.cable.telstraclear.net [121.73.68.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lapse.rw.madduck.net", Issuer "CAcert Class 3 Root" (verified OK)) by clegg.madduck.net (postfix) with ESMTPS id AC61E1D4099 for ; Mon, 25 Jan 2010 08:46:17 +0100 (CET) Received: by lapse.rw.madduck.net (Postfix, from userid 1000) id 0F621A83; Mon, 25 Jan 2010 20:43:33 +1300 (NZDT) Date: Mon, 25 Jan 2010 20:43:33 +1300 From: martin f krafft To: notmuch@notmuchmail.org Message-ID: <20100125074332.GA9417@lapse.rw.madduck.net> Mail-Followup-To: notmuch@notmuchmail.org References: <20100111221909.GA30299@lapse.rw.madduck.net> <1263267603-sup-302@elise> <20100112045152.GA15275@lapse.rw.madduck.net> <20100114203730.GE4691@lapse.rw.madduck.net> <20100125004659.GA24818@lapse.rw.madduck.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: X-Motto: Keep the good times rollin' X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-trunk-686 i686 X-Spamtrap: madduck.bogus@madduck.net X-Subliminal-Message: debian/rules! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at clegg X-Virus-Status: Clean Subject: Re: [notmuch] Git as notmuch object store (was: Potential problem using Git for mail) 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, 25 Jan 2010 07:46:24 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Asheesh Laroia [2010.01.25.1819 +1300]: > You say "Ouch" but you should know Dovecot *already* does this. I > don't mind interoperating with that. > > See http://wiki.dovecot.org/MailboxFormat/Maildir, section "Issues > with the specification", subsection "Locking". I term this theQ > famous readdir() race. Yikes. IMAP (including dovecot) just SUCKS. > Without this lock, Maildir is fundamentally incompatible with IMAP > -- one Maildir-using process modifying message flags could make > a different Maildir-using process think said message is actually > deleted. In the case of temporary disappearing mails in Mutt > locally, that's not the end of the world. For IMAP, it will make > the IMAP daemon (one of the Maildir-using processes) send a note > to IMAP clients saying that the message has been deleted and > expunged. [=E2=80=A6] > Just don't fall into the trap of thinking Maildir is compatible > with IMAP. It's not, because as I understand things, the > filesystem doesn't guarantee that you can actually iterate across > a directory's files if another process is modifying the list of > files. This is all perfect reason to concentrate even more on designing a store that could potentially make IMAP obsolete once and for all! The current idea is to sync Git downstream only, and find a way to keep multiple copies of a tagstore in sync, by way of the "server instance" (where mail is received/delivered). Deleting messages would then be something like setting the notmuch::deleted tag, which clients would honour; on the server, a cleanup process would run regularly to actually delete the blobs associated with deleted messages. This would then propogate the next time one pulls from Git. Whether to store history (commit objects) or just collections (tree objects) needs to be investigated. > >But there are still good reasons why you'd want to have IMAP > >capability too, e.g. Webmail. Given the atomicity problems that > >come from Git, maybe an IMAP server reading from the Git store > >would make sense. >=20 > It wouldn't be too hard to write a FUSE filesystem that presented > an interface to a Git repository that didn't allow the contents of > files to be modified. Then Dovecot could think it's interacting > with the filesystem. Yes, a FUSE layer (which adds a daemon), or a lightweight access API via libnotmuch. Probably the former using the latter. ;) > Aww, I like Maildir flags, but if there's a sync tool, I'm fine > with that. [=E2=80=A6] > I'm not sure, but maybe it's safe if you refuse to ever modify > a message's flags in the filename. The main point is that there is nothing really in Maildir filenames that you couldn't equally (and possibly better) represent in the notmuch::* tag namespace, and then there is benefit in only having one used primarily (which means notmuchsync can do whatever it wants without affecting or messing with notmuch). --=20 martin | http://madduck.net/ | http://two.sentenc.es/ =20 "if I can't dance, i don't want to be part of your revolution." - emma goldman =20 spamtraps: madduck.bogus@madduck.net --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="digital_signature_gpg.asc" Content-Description: Digital signature (see http://martin-krafft.net/gpg/) Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAktdS6EACgkQIgvIgzMMSnWJbQCcDBrG49F1N5EjJOG3+FuC8CRM Tc8AoODJpWEfzMvp2pgeNX3hUNenQodF =54WU -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62--