a7/b19e6787574bf0ee7a9ad98f6d1399b1806f6b

   1 Return-Path: <madduck@lapse.rw.madduck.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id DEBF5431FC0\r
   6         for <notmuch@notmuchmail.org>; Sun, 24 Jan 2010 23:46:23 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.599\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-2.599] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id 6paPulOmEjdQ for <notmuch@notmuchmail.org>;\r
  16         Sun, 24 Jan 2010 23:46:23 -0800 (PST)\r
  17 Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96])\r
  18         by olra.theworths.org (Postfix) with ESMTP id A5DE4431FBC\r
  19         for <notmuch@notmuchmail.org>; Sun, 24 Jan 2010 23:46:22 -0800 (PST)\r
  20 Received: from lapse.rw.madduck.net (121-73-68-174.cable.telstraclear.net\r
  21         [121.73.68.174])\r
  22         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  23         (Client CN "lapse.rw.madduck.net",\r
  24         Issuer "CAcert Class 3 Root" (verified OK))\r
  25         by clegg.madduck.net (postfix) with ESMTPS id AC61E1D4099\r
  26         for <notmuch@notmuchmail.org>; Mon, 25 Jan 2010 08:46:17 +0100 (CET)\r
  27 Received: by lapse.rw.madduck.net (Postfix, from userid 1000)\r
  28         id 0F621A83; Mon, 25 Jan 2010 20:43:33 +1300 (NZDT)\r
  29 Date: Mon, 25 Jan 2010 20:43:33 +1300\r
  30 From: martin f krafft <madduck@madduck.net>\r
  31 To: notmuch@notmuchmail.org\r
  32 Message-ID: <20100125074332.GA9417@lapse.rw.madduck.net>\r
  33 Mail-Followup-To: notmuch@notmuchmail.org\r
  34 References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  35         <1263267603-sup-302@elise>\r
  36         <20100112045152.GA15275@lapse.rw.madduck.net>\r
  37         <alpine.DEB.2.00.1001140254240.27198@vellum>\r
  38         <20100114203730.GE4691@lapse.rw.madduck.net>\r
  39         <alpine.DEB.2.00.1001210124590.24778@localhost>\r
  40         <20100125004659.GA24818@lapse.rw.madduck.net>\r
  41         <alpine.DEB.2.00.1001250009500.27181@localhost>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: multipart/signed; micalg=pgp-ripemd160;\r
  44         protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62"\r
  45 Content-Disposition: inline\r
  46 In-Reply-To: <alpine.DEB.2.00.1001250009500.27181@localhost>\r
  47 X-Motto: Keep the good times rollin'\r
  48 X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-trunk-686 i686\r
  49 X-Spamtrap: madduck.bogus@madduck.net\r
  50 X-Subliminal-Message: debian/rules!\r
  51 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  52 X-Virus-Scanned: clamav-milter 0.95.3 at clegg\r
  53 X-Virus-Status: Clean\r
  54 Subject: Re: [notmuch] Git as notmuch object store (was: Potential problem\r
  55  using Git for mail)\r
  56 X-BeenThere: notmuch@notmuchmail.org\r
  57 X-Mailman-Version: 2.1.13\r
  58 Precedence: list\r
  59 List-Id: "Use and development of the notmuch mail system."\r
  60         <notmuch.notmuchmail.org>\r
  61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  62         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  64 List-Post: <mailto:notmuch@notmuchmail.org>\r
  65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  67         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  68 X-List-Received-Date: Mon, 25 Jan 2010 07:46:24 -0000\r
  69 \r
  70 \r
  71 --+QahgC5+KEYLbs62\r
  72 Content-Type: text/plain; charset=utf-8\r
  73 Content-Disposition: inline\r
  74 Content-Transfer-Encoding: quoted-printable\r
  75 \r
  76 also sprach Asheesh Laroia <asheesh@asheesh.org> [2010.01.25.1819 +1300]:\r
  77 > You say "Ouch" but you should know Dovecot *already* does this. I\r
  78 > don't mind interoperating with that.\r
  79 >\r
  80 > See http://wiki.dovecot.org/MailboxFormat/Maildir, section "Issues\r
  81 > with the specification", subsection "Locking". I term this theQ\r
  82 > famous readdir() race.\r
  83 \r
  84 Yikes. IMAP (including dovecot) just SUCKS.\r
  85 \r
  86 > Without this lock, Maildir is fundamentally incompatible with IMAP\r
  87 > -- one Maildir-using process modifying message flags could make\r
  88 > a different Maildir-using process think said message is actually\r
  89 > deleted. In the case of temporary disappearing mails in Mutt\r
  90 > locally, that's not the end of the world. For IMAP, it will make\r
  91 > the IMAP daemon (one of the Maildir-using processes) send a note\r
  92 > to IMAP clients saying that the message has been deleted and\r
  93 > expunged.\r
  94 [=E2=80=A6]\r
  95 > Just don't fall into the trap of thinking Maildir is compatible\r
  96 > with IMAP. It's not, because as I understand things, the\r
  97 > filesystem doesn't guarantee that you can actually iterate across\r
  98 > a directory's files if another process is modifying the list of\r
  99 > files.\r
 100 \r
 101 This is all perfect reason to concentrate even more on designing\r
 102 a store that could potentially make IMAP obsolete once and for all!\r
 103 \r
 104 The current idea is to sync Git downstream only, and find a way to\r
 105 keep multiple copies of a tagstore in sync, by way of the "server\r
 106 instance" (where mail is received/delivered). Deleting messages\r
 107 would then be something like setting the notmuch::deleted tag, which\r
 108 clients would honour; on the server, a cleanup process would run\r
 109 regularly to actually delete the blobs associated with deleted\r
 110 messages. This would then propogate the next time one pulls from\r
 111 Git.\r
 112 \r
 113 Whether to store history (commit objects) or just collections (tree\r
 114 objects) needs to be investigated.\r
 115 \r
 116 > >But there are still good reasons why you'd want to have IMAP\r
 117 > >capability too, e.g. Webmail. Given the atomicity problems that\r
 118 > >come from Git, maybe an IMAP server reading from the Git store\r
 119 > >would make sense.\r
 120 >=20\r
 121 > It wouldn't be too hard to write a FUSE filesystem that presented\r
 122 > an interface to a Git repository that didn't allow the contents of\r
 123 > files to be modified. Then Dovecot could think it's interacting\r
 124 > with the filesystem.\r
 125 \r
 126 Yes, a FUSE layer (which adds a daemon), or a lightweight access\r
 127 API via libnotmuch. Probably the former using the latter. ;)\r
 128 \r
 129 > Aww, I like Maildir flags, but if there's a sync tool, I'm fine\r
 130 > with that.\r
 131 [=E2=80=A6]\r
 132 > I'm not sure, but maybe it's safe if you refuse to ever modify\r
 133 > a message's flags in the filename.\r
 134 \r
 135 The main point is that there is nothing really in Maildir filenames\r
 136 that you couldn't equally (and possibly better) represent in the\r
 137 notmuch::* tag namespace, and then there is benefit in only having\r
 138 one used primarily (which means notmuchsync can do whatever it\r
 139 wants without affecting or messing with notmuch).\r
 140 \r
 141 --=20\r
 142 martin | http://madduck.net/ | http://two.sentenc.es/\r
 143 =20\r
 144 "if I can't dance, i don't want to be part of your revolution."\r
 145                                                         - emma goldman\r
 146 =20\r
 147 spamtraps: madduck.bogus@madduck.net\r
 148 \r
 149 --+QahgC5+KEYLbs62\r
 150 Content-Type: application/pgp-signature; name="digital_signature_gpg.asc"\r
 151 Content-Description: Digital signature (see http://martin-krafft.net/gpg/)\r
 152 Content-Disposition: inline\r
 153 \r
 154 -----BEGIN PGP SIGNATURE-----\r
 155 Version: GnuPG v1.4.10 (GNU/Linux)\r
 156 \r
 157 iEYEAREDAAYFAktdS6EACgkQIgvIgzMMSnWJbQCcDBrG49F1N5EjJOG3+FuC8CRM\r
 158 Tc8AoODJpWEfzMvp2pgeNX3hUNenQodF\r
 159 =54WU\r
 160 -----END PGP SIGNATURE-----\r
 161 \r
 162 --+QahgC5+KEYLbs62--\r