0e/54a3918b5b178ecc46a405ed9cf428b5cd0d63

   1 Return-Path: <sojkam1@fel.cvut.cz>\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 D01E6431FAE\r
   6         for <notmuch@notmuchmail.org>; Mon,  1 Mar 2010 00:57:39 -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: -0.946\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5\r
  12         tests=[AWL=-0.947, BAYES_50=0.001] autolearn=unavailable\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 1lkiIPhyezeY for <notmuch@notmuchmail.org>;\r
  16         Mon,  1 Mar 2010 00:57:37 -0800 (PST)\r
  17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 80C20431FBD\r
  19         for <notmuch@notmuchmail.org>; Mon,  1 Mar 2010 00:57:37 -0800 (PST)\r
  20 Received: from localhost (unknown [192.168.200.4])\r
  21         by max.feld.cvut.cz (Postfix) with ESMTP id 3431C19F3318;\r
  22         Mon,  1 Mar 2010 09:57:29 +0100 (CET)\r
  23 X-Virus-Scanned: IMAP AMAVIS\r
  24 Received: from max.feld.cvut.cz ([192.168.200.1])\r
  25         by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
  26         port 10044)\r
  27         with ESMTP id T1Mv-0uFBlb9; Mon,  1 Mar 2010 09:57:27 +0100 (CET)\r
  28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
  29         by max.feld.cvut.cz (Postfix) with ESMTP id 9B1D419F330A;\r
  30         Mon,  1 Mar 2010 09:57:27 +0100 (CET)\r
  31 Received: from steelpick.localdomain (k335-30.felk.cvut.cz [147.32.86.30])\r
  32         (Authenticated sender: sojkam1)\r
  33         by imap.feld.cvut.cz (Postfix) with ESMTPSA id 23EBFFA003;\r
  34         Mon,  1 Mar 2010 09:57:26 +0100 (CET)\r
  35 Received: from wsh by steelpick.localdomain with local (Exim 4.71)\r
  36         (envelope-from <sojkam1@fel.cvut.cz>)\r
  37         id 1Nm1RO-0003CM-MR; Mon, 01 Mar 2010 09:57:26 +0100\r
  38 From: Michal Sojka <sojkam1@fel.cvut.cz>\r
  39 To: Carl Worth <cworth@cworth.org>, Sebastian Spaeth <Sebastian@SSpaeth.de>,\r
  40         notmuch@notmuchmail.org\r
  41 In-Reply-To: <87wry2wl7p.fsf@yoom.home.cworth.org>\r
  42 References: <87pr57jvkz.fsf@SSpaeth.de> <87wry2wl7p.fsf@yoom.home.cworth.org>\r
  43 Date: Mon, 01 Mar 2010 09:57:26 +0100\r
  44 Message-ID: <87ljecmnbd.fsf@steelpick.localdomain>\r
  45 MIME-Version: 1.0\r
  46 Content-Type: text/plain; charset=us-ascii\r
  47 Subject: Re: [notmuch] Introducing notmuchsync\r
  48 X-BeenThere: notmuch@notmuchmail.org\r
  49 X-Mailman-Version: 2.1.13\r
  50 Precedence: list\r
  51 List-Id: "Use and development of the notmuch mail system."\r
  52         <notmuch.notmuchmail.org>\r
  53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  56 List-Post: <mailto:notmuch@notmuchmail.org>\r
  57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  60 X-List-Received-Date: Mon, 01 Mar 2010 08:57:40 -0000\r
  61 \r
  62 On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth <cworth@cworth.org> wrote:\r
  63 > Elsewhere in the thread Jameson Rollins wrote:\r
  64 > > I should have mentioned in my previous mail that I think this tool is\r
  65 > > a great idea, and I plan on using it.  I just hope that all of it's\r
  66 > > functionality will be integrated directly into notmuch itself.\r
  67 > \r
  68 > I think that's the open question still. How much of this kind of\r
  69 > functionality do we integrate into notmuch itself. I don't know the\r
  70 > answer to that question yet, but I'm quite happy to see people\r
  71 > experimenting with doing scripts like this on top of notmuch already.\r
  72 \r
  73 Hi, when you are on this topic, I'll put my two cents in. Currently\r
  74 notmuch works only with mail-store comprised of files. People want to\r
  75 work with their mails on multiple computers so there are several\r
  76 ideas/solutions how to achieve that. Notmuchsync, which plays well with\r
  77 offlineimap, is one of them. Another idea is Git based mail-store, which\r
  78 I would really like to have.\r
  79 \r
  80 If we want to make notmuch work with Git-based mail-store, it will be\r
  81 necessary to make the interface between notmuch core and mail-store\r
  82 handling code a bit more abstract so that it will be possible to\r
  83 configure mail-store type to be used.\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 2. get the list of new mails which need to be indexed\r
  91    (current notmuch does recursive file traversal, for git-based store\r
  92    it will be something like system("git diff-tree --name-status ...")\r
  93 3. add/remove tags for a given message (this will be NULL for current\r
  94    notmuch functionality)\r
  95 \r
  96 This way the mail-store will be able to store both mails and\r
  97 corresponding tags and in case of git, it will be easy to synchronize\r
  98 mail-stores on multiple computers.\r
  99 \r
 100 Now, if we have this, it would be very easy to add support for\r
 101 Maildir-based mail-store. The implementation of the first two methods\r
 102 would be the same as what is currently in notmuch and the third method\r
 103 would rename files in mailstore if certain tags (such as unread) are\r
 104 added or removed. In case of rename, notmuch database would be\r
 105 immediately updated to reflect the change.\r
 106 \r
 107 So to summarize, I think there should be an abstract layer for\r
 108 handling different types of mail-store. I can see at least three\r
 109 possible implementations of this abstract interface: 1) immutable\r
 110 mail-store (as currently implemented in notmuch) 2) Maildir-based\r
 111 mail-store for limited synchronization with other Maildir tools and \r
 112 3) git-based mail-store for full synchronization.\r
 113 \r
 114 I've already started working on this, but I'm still in the state where I\r
 115 mainly study how notmuch works in order not to break its current\r
 116 functionality.\r
 117 \r
 118 I'd like to hear what others think about this idea.\r
 119 \r
 120 Bye\r
 121 Michal\r