bb/b73d10b9df9759b366d80d25b207b4d8e88eb9

   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 A1C10431FBC\r
   6         for <notmuch@notmuchmail.org>; Wed, 13 Jan 2010 17:32:10 -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.821\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=-0.022, BAYES_50=0.001] 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 lIzYD6TKr9K5; Wed, 13 Jan 2010 17:32:09 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id 95AC4431FAE;\r
  18         Wed, 13 Jan 2010 17:32:09 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 43112254090; Wed, 13 Jan 2010 17:32:09 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: martin f krafft <madduck@madduck.net>, mailtags discussion list\r
  23         <mailtags@lists.madduck.net>\r
  24 In-Reply-To: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  25 References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  26 Date: Wed, 13 Jan 2010 17:32:08 -0800\r
  27 Message-ID: <87hbqpfp47.fsf@yoom.home.cworth.org>\r
  28 MIME-Version: 1.0\r
  29 Content-Type: multipart/signed; boundary="=-=-=";\r
  30         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  31 Cc: notmuch discussion list <notmuch@notmuchmail.org>\r
  32 Subject: Re: [notmuch] Idea for storing tags\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: Thu, 14 Jan 2010 01:32:10 -0000\r
  46 \r
  47 --=-=-=\r
  48 \r
  49 On Tue, 12 Jan 2010 11:19:09 +1300, martin f krafft <madduck@madduck.net> wrote:\r
  50 > 1. External database, which has the downside of not being\r
  51 >    synchronisable with standard IMAP, like the rest of your mail\r
  52 >    (assuming you use IMAP). Also, it's possible for mailstore and\r
  53 >    database to get out of sync.\r
  54 \r
  55 Yes. This approach requires some external means of synchronizing the\r
  56 tags from one system to another.\r
  57 \r
  58 I don't understand what it would mean to have the mailstore and the\r
  59 database out of synch here. This approach doesn't have the tags in the\r
  60 mailstore by definition, right?\r
  61 \r
  62 > How about using pseudo-mails stored in Maildir and synchronised by\r
  63 > IMAP? E.g. every folder could have a subfolder .TAGS and if we find\r
  64 > a way to smartly pair messages between parent and subfolder, we'd\r
  65 > have a tag store alongside the mailstore it refers to, but without\r
  66 > the danger of leakage, and without having to rewrite messages.\r
  67 ...\r
  68 > Anyway, the idea is out now. Thoughts?\r
  69 \r
  70 There are a couple of problems that I don't see addressed at all with\r
  71 this approach. The first is that there's not a one-to-one mapping\r
  72 between messages and files in the mail store. (I'm CCed on a lot of list\r
  73 mail meaning that I have multiple files in my mail store for a single\r
  74 message.)\r
  75 \r
  76 Second, the only reason I would be interested in synchronizing mail\r
  77 between two systems is so that I could manipulate the tag data in\r
  78 multiple places, (that is, remove the "unread" tag whether on my\r
  79 network-disconnected laptop or via web-mail when away from my\r
  80 laptop). Using imap for synchronizing a file of tags within the mail\r
  81 store gives you no mechanism for doing any sort of conflict resolution,\r
  82 right? (Which I think in almost all cases is going to be quite trivial\r
  83 if there's a chance for a program to resolve it.)\r
  84 \r
  85 So it sounds to me like we're going to need *something* custom for doing\r
  86 the synchronization, (to handle modifications on both ends). At which\r
  87 point there's only disadvantages to keeping the data inside the\r
  88 mailstore, and there's also no disadvantage left to keeping the data\r
  89 inside a database. [*]\r
  90 \r
  91 [*] Though, I think a plain-text file with tags managed with something\r
  92 like git (and perhaps a custom merger) could save a lot of work. Or\r
  93 perhaps a plain-text journal of tag manipulations on either end that\r
  94 could be replayed on the other.\r
  95 \r
  96 -Carl\r
  97 \r
  98 --=-=-=\r
  99 Content-Type: application/pgp-signature\r
 100 \r
 101 -----BEGIN PGP SIGNATURE-----\r
 102 Version: GnuPG v1.4.10 (GNU/Linux)\r
 103 \r
 104 iD8DBQFLTnQZ6JDdNq8qSWgRAkEHAJ4wqrIK/iL1iB8FzudLc40ToYs8ZACcD3wu\r
 105 mgLY8cAlsCbTaPTdD7Zou8o=\r
 106 =HSmh\r
 107 -----END PGP SIGNATURE-----\r
 108 --=-=-=--\r