40/b0a9408accf73106c93ce98022248a3cbc2717

   1 Return-Path: <bgamari@gmail.com>\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 5CC74431FC3\r
   6         for <notmuch@notmuchmail.org>; Mon,  1 Mar 2010 08:27:20 -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: -1.442\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5\r
  12         tests=[AWL=-0.332, BAYES_05=-1.11] 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 SNGkimUFunby for <notmuch@notmuchmail.org>;\r
  16         Mon,  1 Mar 2010 08:27:19 -0800 (PST)\r
  17 Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com\r
  18         [209.85.212.53])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 6A573431FBD\r
  20         for <notmuch@notmuchmail.org>; Mon,  1 Mar 2010 08:27:19 -0800 (PST)\r
  21 Received: by vws5 with SMTP id 5so22534vws.26\r
  22         for <notmuch@notmuchmail.org>; Mon, 01 Mar 2010 08:27:11 -0800 (PST)\r
  23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  24         h=domainkey-signature:received:received:content-type:subject:from:to\r
  25         :in-reply-to:references:date:message-id:user-agent\r
  26         :content-transfer-encoding;\r
  27         bh=h3zzXFxabL7VDuMTj3FTFcd5bQHl1wapUjdxZlQQcPw=;\r
  28         b=VDtVBKL5kusFzrX24CsrViP0jDtQHqfIgUjXcC7iHTpEKlxTzeKacrlEdtun3x0Mq8\r
  29         pBblDVcVSCEcIlgctzFJiRE0dpPKn4nk28u0IM99VskVNhFwtLPaZPi0eUabT8P0Dxw3\r
  30         9T8cgOQwN9KetxIXE7ta1QJPfM+RiAVU0mN/s=\r
  31 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  32         h=content-type:subject:from:to:in-reply-to:references:date:message-id\r
  33         :user-agent:content-transfer-encoding;\r
  34         b=JoV3f4Ia0cl8DZxC9Xcf5QHnNqy4V3iWdR4zBF9J9yO0GvdWFsIx/6xJ232j40RZBN\r
  35         nL1AOENvVQEAb4ZDibXDoXkh7tDPdbou4YUHIJ7i5VmQOu1ls+k69n36ITiyquwfCJ6Y\r
  36         vR3rb2OIZ1fCZyJtrLp5termgG9Py63dlbiPM=\r
  37 Received: by 10.220.124.24 with SMTP id s24mr3315080vcr.182.1267460831289;\r
  38         Mon, 01 Mar 2010 08:27:11 -0800 (PST)\r
  39 Received: from localhost (umass-959-186.wireless.umass.edu [128.119.77.186])\r
  40         by mx.google.com with ESMTPS id 29sm31434003vws.3.2010.03.01.08.27.09\r
  41         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  42         Mon, 01 Mar 2010 08:27:09 -0800 (PST)\r
  43 Content-Type: text/plain; charset=UTF-8\r
  44 From: Ben Gamari <bgamari@gmail.com>\r
  45 To: notmuch <notmuch@notmuchmail.org>\r
  46 In-reply-to: <87ljecmnbd.fsf@steelpick.localdomain>\r
  47 References: <87pr57jvkz.fsf@SSpaeth.de> <87wry2wl7p.fsf@yoom.home.cworth.org>\r
  48         <87ljecmnbd.fsf@steelpick.localdomain>\r
  49 Date: Mon, 01 Mar 2010 11:27:07 -0500\r
  50 Message-Id: <1267459947-sup-6640@ben-laptop>\r
  51 User-Agent: Sup/git\r
  52 Content-Transfer-Encoding: 8bit\r
  53 Subject: Re: [notmuch] Introducing notmuchsync\r
  54 X-BeenThere: notmuch@notmuchmail.org\r
  55 X-Mailman-Version: 2.1.13\r
  56 Precedence: list\r
  57 List-Id: "Use and development of the notmuch mail system."\r
  58         <notmuch.notmuchmail.org>\r
  59 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  60         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  61 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  62 List-Post: <mailto:notmuch@notmuchmail.org>\r
  63 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  64 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  66 X-List-Received-Date: Mon, 01 Mar 2010 16:27:20 -0000\r
  67 \r
  68 Excerpts from Michal Sojka's message of Mon Mar 01 03:57:26 -0500 2010:\r
  69 > Hi, when you are on this topic, I'll put my two cents in. Currently\r
  70 > notmuch works only with mail-store comprised of files. People want to\r
  71 > work with their mails on multiple computers so there are several\r
  72 > ideas/solutions how to achieve that. Notmuchsync, which plays well with\r
  73 > offlineimap, is one of them. Another idea is Git based mail-store, which\r
  74 > I would really like to have.\r
  75 > \r
  76 > If we want to make notmuch work with Git-based mail-store, it will be\r
  77 > necessary to make the interface between notmuch core and mail-store\r
  78 > handling code a bit more abstract so that it will be possible to\r
  79 > configure mail-store type to be used.\r
  80 \r
  81 I agree that we should make notmuch less tied to maildirs as the only\r
  82 possible mailstore. In the interest of simplicity, however, it's\r
  83 important to keep the surface area of the interface down.\r
  84 > \r
  85 > This abstract mail-store interface will contain methods for the\r
  86 > following operations:\r
  87 > 1. read mail identified by a path from mail-store\r
  88 >    (current notmuch uses fread() for this, for git this will be\r
  89 >    something like system("git cat-file ..."))\r
  90 >\r
  91 Yep. Seems reasonable.\r
  92 \r
  93 > 2. get the list of new mails which need to be indexed\r
  94 >    (current notmuch does recursive file traversal, for git-based store\r
  95 >    it will be something like system("git diff-tree --name-status ...")\r
  96 >\r
  97 Is this really necessary? Another option (which I believe has been\r
  98 mentioned here in the past) is to simply pass notmuch new a list of\r
  99 message "paths" to add (although I'm not sure if many mail delivery\r
 100 programs give you that sort of information). How do you propose that the\r
 101 backends keep track of what mail has been indexed?\r
 102 \r
 103 > 3. add/remove tags for a given message (this will be NULL for current\r
 104 >    notmuch functionality)\r
 105 Yep, makes sense.\r
 106 \r
 107 > \r
 108 > This way the mail-store will be able to store both mails and\r
 109 > corresponding tags and in case of git, it will be easy to synchronize\r
 110 > mail-stores on multiple computers.\r
 111 \r
 112 Sounds great. Can't wait!\r
 113 > \r
 114 > Now, if we have this, it would be very easy to add support for\r
 115 > Maildir-based mail-store. The implementation of the first two methods\r
 116 > would be the same as what is currently in notmuch and the third method\r
 117 > would rename files in mailstore if certain tags (such as unread) are\r
 118 > added or removed. In case of rename, notmuch database would be\r
 119 > immediately updated to reflect the change.\r
 120 > \r
 121 The interface here seems a little vague. How would the backend notify\r
 122 notmuch that the filename has changed?\r
 123 \r
 124 > So to summarize, I think there should be an abstract layer for\r
 125 > handling different types of mail-store. I can see at least three\r
 126 > possible implementations of this abstract interface: 1) immutable\r
 127 > mail-store (as currently implemented in notmuch) 2) Maildir-based\r
 128 > mail-store for limited synchronization with other Maildir tools and \r
 129 > 3) git-based mail-store for full synchronization.\r
 130 \r
 131 Don't forget mbox. It seems like it would be pretty trivial to\r
 132 implement (although I'm not sure what performance would look like).\r
 133 > \r
 134 > I've already started working on this, but I'm still in the state where I\r
 135 > mainly study how notmuch works in order not to break its current\r
 136 > functionality.\r
 137 \r
 138 With all of this infrastructure, it seems like it wouldn't be too\r
 139 difficult to support messages from multiple backends in a single index.\r
 140 Not sure if people would be interested enough to warrant the added\r
 141 complexity though.\r
 142 \r
 143 > \r
 144 > I'd like to hear what others think about this idea.\r
 145 > \r
 146 That's my uninformed opinion. Take it with an appropriately sized grain\r
 147 of salt. I do think that some sort of abstraction will be necessary\r
 148 though. I'm glad you're taking a look at this. I've been wanting to\r
 149 start hacking away at some sort of prototype git backend, but I haven't\r
 150 wanted to start before we have the appropriate infrastructure in\r
 151 notmuch.\r
 152 \r
 153 Cheers,\r
 154 \r
 155 - Ben\r