27/af96e16fe9ddbd03d1ba5556ad144dbe1a3081

   1 Return-Path: <cworth@cworth.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 913BA4196F2\r
   6         for <notmuch@notmuchmail.org>; Tue, 13 Apr 2010 10:53:15 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 9sDQMeyOUYS2; Tue, 13 Apr 2010 10:53:13 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 22869431FC1;\r
  19         Tue, 13 Apr 2010 10:53:13 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id C44D55883A6; Tue, 13 Apr 2010 10:53:12 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
  24 Subject: Re: [PATCH 1/4] Mailstore abstraction interface\r
  25 In-Reply-To: <1270737766-29237-2-git-send-email-sojkam1@fel.cvut.cz>\r
  26 References: <1270737766-29237-1-git-send-email-sojkam1@fel.cvut.cz>\r
  27         <1270737766-29237-2-git-send-email-sojkam1@fel.cvut.cz>\r
  28 Date: Tue, 13 Apr 2010 10:53:12 -0700\r
  29 Message-ID: <87aat7kznb.fsf@yoom.home.cworth.org>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: multipart/signed; boundary="=-=-=";\r
  32         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  33 X-BeenThere: notmuch@notmuchmail.org\r
  34 X-Mailman-Version: 2.1.13\r
  35 Precedence: list\r
  36 List-Id: "Use and development of the notmuch mail system."\r
  37         <notmuch.notmuchmail.org>\r
  38 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  40 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  41 List-Post: <mailto:notmuch@notmuchmail.org>\r
  42 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  43 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  45 X-List-Received-Date: Tue, 13 Apr 2010 17:53:15 -0000\r
  46 \r
  47 --=-=-=\r
  48 \r
  49 On Thu,  8 Apr 2010 16:42:43 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
  50 > The goal of mailstore abstraction is to allow notmuch to store tags\r
  51 > together with email messages. The abstract interface is needed because\r
  52 > people want to use different ways of storing their emails. Currently,\r
  53 > there exists implementation for two types of mailstore - plain files\r
  54 > and maildir. It is expected that additional git-based mailstore will\r
  55 > be developed later.\r
  56 \r
  57 I don't agree with the approach being taken here.\r
  58 \r
  59 I don't think that the expectation of future need is a good basis for\r
  60 adding a level of abstraction now. This gives us current costs without\r
  61 benefit.\r
  62 \r
  63 Meanwhile, the two different mail stores that you are currently support\r
  64 ("plain" and "maildir") aren't really different types. We do already\r
  65 have code within notmuch to detect whether any particular directory is a\r
  66 maildir, (with the heuristic of looking for child directories named\r
  67 "cur", "new", and "tmp"). So I think we can and should support both\r
  68 maildir and non-maildir mail storage just fine.\r
  69 \r
  70 The question of "once you have maildir storage, should you synchronize\r
  71 that tags" is quite separate. The answer there might be "yes", "no", or\r
  72 "let the user decide". But if it is configurable, then the configuration\r
  73 should be something like\r
  74 \r
  75         [maildir]\r
  76         synchronize_flags=yes\r
  77 \r
  78 rather than\r
  79 \r
  80         [mailstore]\r
  81         type=maildir\r
  82 \r
  83 This series is looking like one of the most complete approaches to\r
  84 maildir-flag synchronization, (and I like some of the motivation that\r
  85 leads to "notmuch cat"). But I think the mailstore abstraction is\r
  86 largely a distraction from the real features here.\r
  87 \r
  88 -Carl\r
  89 \r
  90 --=-=-=\r
  91 Content-Type: application/pgp-signature\r
  92 \r
  93 -----BEGIN PGP SIGNATURE-----\r
  94 Version: GnuPG v1.4.10 (GNU/Linux)\r
  95 \r
  96 iD8DBQFLxK+I6JDdNq8qSWgRAlnQAJsE+t03y5AFUfgZG6lKv06s3KDKpQCfc0lD\r
  97 EDT6dQbukg07Hyto2SvvDBc=\r
  98 =TUnE\r
  99 -----END PGP SIGNATURE-----\r
 100 --=-=-=--\r