87/0321452ddb697e63a12e0bace8543479dfa996

   1 Return-Path: <asheesh@asheesh.org>\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 C6CF1431FBC\r
   6         for <notmuch@notmuchmail.org>; Sun, 24 Jan 2010 21:19:37 -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 qowNVyp-37QI for <notmuch@notmuchmail.org>;\r
  16         Sun, 24 Jan 2010 21:19:35 -0800 (PST)\r
  17 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 72AEC431FAE\r
  19         for <notmuch@notmuchmail.org>; Sun, 24 Jan 2010 21:19:35 -0800 (PST)\r
  20 Received: from rose ([199.199.210.158])\r
  21         by mx.perfora.net (node=mxus1) with ESMTP (Nemesis)\r
  22         id 0LeONZ-1O9Pr63UYX-00qgQ2 for notmuch@notmuchmail.org;\r
  23         Mon, 25 Jan 2010 00:19:34 -0500\r
  24 Received: from renaissance (localhost [127.0.0.1])\r
  25         by rose (Postfix) with ESMTPS id A66042E0133;\r
  26         Mon, 25 Jan 2010 05:20:41 +0000 (UTC)\r
  27 Received: from localhost (localhost [127.0.0.1])\r
  28         by renaissance (Postfix) with ESMTPS id 2FBBFCDC8B;\r
  29         Mon, 25 Jan 2010 00:19:25 -0500 (EST)\r
  30 Date: Mon, 25 Jan 2010 00:19:24 -0500 (EST)\r
  31 From: Asheesh Laroia <asheesh@asheesh.org>\r
  32 X-X-Sender: paulproteus@localhost\r
  33 To: martin f krafft <madduck@madduck.net>\r
  34 In-Reply-To: <20100125004659.GA24818@lapse.rw.madduck.net>\r
  35 Message-ID: <alpine.DEB.2.00.1001250009500.27181@localhost>\r
  36 References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  37         <1263267603-sup-302@elise>\r
  38         <20100112045152.GA15275@lapse.rw.madduck.net>\r
  39         <alpine.DEB.2.00.1001140254240.27198@vellum>\r
  40         <20100114203730.GE4691@lapse.rw.madduck.net>\r
  41         <alpine.DEB.2.00.1001210124590.24778@localhost>\r
  42         <20100125004659.GA24818@lapse.rw.madduck.net>\r
  43 User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)\r
  44 X-OpenPGP-Key-ID: 0x70096AD1\r
  45 MIME-Version: 1.0\r
  46 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-756071938-1264396765=:27181"\r
  47 Cc: notmuch <notmuch@notmuchmail.org>\r
  48 Subject: Re: [notmuch] Git as notmuch object store (was: Potential problem\r
  49  using Git for mail)\r
  50 X-BeenThere: notmuch@notmuchmail.org\r
  51 X-Mailman-Version: 2.1.13\r
  52 Precedence: list\r
  53 List-Id: "Use and development of the notmuch mail system."\r
  54         <notmuch.notmuchmail.org>\r
  55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  58 List-Post: <mailto:notmuch@notmuchmail.org>\r
  59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  62 X-List-Received-Date: Mon, 25 Jan 2010 05:19:37 -0000\r
  63 \r
  64   This message is in MIME format.  The first part should be readable text,\r
  65   while the remaining parts are likely unreadable without MIME-aware tools.\r
  66 \r
  67 --8323328-756071938-1264396765=:27181\r
  68 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed\r
  69 Content-Transfer-Encoding: 8BIT\r
  70 \r
  71 On Mon, 25 Jan 2010, martin f krafft wrote:\r
  72 \r
  73 > also sprach Asheesh Laroia <asheesh@asheesh.org> [2010.01.21.1928 \r
  74 > +1300]:\r
  75 >>> I suppose that I never actually considered merges on the IMAP server \r
  76 >>> side, but obviously the IMAP server has to work off a clone, and that \r
  77 >>> means it needs to merge.\r
  78 >>\r
  79 >> It's not "merge" that's unsafe; that just builds a tree in the git \r
  80 >> index (assuming no conflicts). It's the ensuing process of git writing \r
  81 >> a tree to the filesystem that is problematic.\r
  82 >\r
  83 > There is no way to make that atomic, I am afraid. As you say.\r
  84 >\r
  85 >> I could probably actually write a wrapper that locks the Maildir while \r
  86 >> git is operating. It would probably be specific to each IMAP server.\r
  87 >\r
  88 > Ouch! I'd really rather not go there.\r
  89 \r
  90 You say "Ouch" but you should know Dovecot *already* does this. I don't \r
  91 mind interoperating with that.\r
  92 \r
  93 See http://wiki.dovecot.org/MailboxFormat/Maildir, section "Issues with \r
  94 the specification", subsection "Locking". I term this the famous readdir() \r
  95 race. Without this lock, Maildir is fundamentally incompatible with IMAP \r
  96 -- one Maildir-using process modifying message flags could make a \r
  97 different Maildir-using process think said message is actually deleted. In \r
  98 the case of temporary disappearing mails in Mutt locally, that's not the \r
  99 end of the world. For IMAP, it will make the IMAP daemon (one of the \r
 100 Maildir-using processes) send a note to IMAP clients saying that the \r
 101 message has been deleted and expunged.\r
 102 \r
 103 >> Note that this mean git is fundamentally incompatible with Maildir, not \r
 104 >> just IMAP servers.\r
 105 >\r
 106 > We had an idea about using Git to replace IMAP altogether, along with \r
 107 > making notmuch use a bare Git repository as object store. The idea is \r
 108 > that notmuch uses low-level Git commands to access the .git repository \r
 109 > (from which you can still checkout a tree tying the blobs into a \r
 110 > Maildir). The benefit would be compression, lower inode count (due to \r
 111 > packs), and backups using clones/merges.\r
 112 \r
 113 Sure, that makes sense to me.\r
 114 \r
 115 > You could either have the MDA write to a Git repo on the server side and \r
 116 > use git packs to download mail to a local clone, or one could have e.g. \r
 117 > offlineimap grow a Git storage backend. The interface to notmuch would \r
 118 > be the same.\r
 119 \r
 120 Yeah, I generally like this.\r
 121 \r
 122 > If we used this, all the rename and delete code would be refactored into \r
 123 > Git and could be removed from notmuch. In addition, notmuch could \r
 124 > actually use Git tree objects to represent the results of searches, and \r
 125 > you could checkout these trees. However, deleting messages from search \r
 126 > results would not have any effect on the message or its existence in \r
 127 > other search results, much like what happens with mairix nowadays.\r
 128 \r
 129 That's okay with me.\r
 130 \r
 131 > I think we all kinda agreed that the Maildir flags should not be used by \r
 132 > notmuch and that things like Sebastian's notmuchsync should be used if \r
 133 > people wanted flags represented in Maildir filenames.\r
 134 \r
 135 Aww, I like Maildir flags, but if there's a sync tool, I'm fine with that.\r
 136 \r
 137 > Instead of a Maildir checkout, notmuch could provide an interface to \r
 138 > browse the store contents in a way that could make it accessible to \r
 139 > mutt. The argument is that with 'notmuch {ls,cat,rm,…}', a mutt backend \r
 140 > could be trivially written. I am not sure about that, but it's worth a \r
 141 > try.\r
 142 \r
 143 Sure.\r
 144 \r
 145 > But there are still good reasons why you'd want to have IMAP capability \r
 146 > too, e.g. Webmail. Given the atomicity problems that come from Git, \r
 147 > maybe an IMAP server reading from the Git store would make sense.\r
 148 \r
 149 It wouldn't be too hard to write a FUSE filesystem that presented an \r
 150 interface to a Git repository that didn't allow the contents of files to \r
 151 be modified. Then Dovecot could think it's interacting with the \r
 152 filesystem.\r
 153 \r
 154 > However, this all sounds like a lot of NIH and reinvention. It's\r
 155 > a bit like the marriage between the hypothetical Maildir2 and Git,\r
 156 > which is definitely worth pursuing. Before we embark on any of this,\r
 157 > however, we'd need to define the way in which Git stores mail.\r
 158 \r
 159 Sure. If it were me, I'd just say, "For phase 1 of notmuch, just have git \r
 160 store Maildir spools." When you need a filesystem interface for e.g. \r
 161 Dovecot, have a FUSE wrapper.\r
 162 \r
 163 See how far that can take you, and then see if version 2 is necessary. \r
 164 (-:\r
 165 \r
 166 > Stewart, you've worked most on this so far. Would you like to share your \r
 167 > thoughts?\r
 168 \r
 169 I'll listen, too.\r
 170 \r
 171 Just don't fall into the trap of thinking Maildir is compatible with IMAP. \r
 172 It's not, because as I understand things, the filesystem doesn't guarantee \r
 173 that you can actually iterate across a directory's files if another \r
 174 process is modifying the list of files.\r
 175 \r
 176 I'm not sure, but maybe it's safe if you refuse to ever modify a \r
 177 message's flags in the filename.\r
 178 \r
 179 Anyway, as I see it, further hacks that aren't much worse than Dovecot's \r
 180 should be considered okay, unless you have a more elegant design up your \r
 181 sleeve.\r
 182 \r
 183 If I'm slightly wrong about something, try to give me the benefit of \r
 184 doubt. It's past midnight. (-:\r
 185 \r
 186 -- Asheesh.\r
 187 \r
 188 -- \r
 189 There's no real need to do housework -- after four years it doesn't get\r
 190 any worse.\r
 191 --8323328-756071938-1264396765=:27181--\r