e9/198c8a4135498fa6c6fe78d70af103eafa423e

   1 Return-Path: <madduck@lapse.rw.madduck.net>\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 0BF8E431FBC\r
   6         for <notmuch@notmuchmail.org>; Tue, 12 Jan 2010 17:24:18 -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.232\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=2.367,\r
  12         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 URU-XxsN2AFi for <notmuch@notmuchmail.org>;\r
  16         Tue, 12 Jan 2010 17:24:17 -0800 (PST)\r
  17 Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96])\r
  18         by olra.theworths.org (Postfix) with ESMTP id AF440431FAE\r
  19         for <notmuch@notmuchmail.org>; Tue, 12 Jan 2010 17:24:16 -0800 (PST)\r
  20 Received: from lapse.rw.madduck.net (unknown\r
  21         [IPv6:2404:130:0:1000:20a:e4ff:fe30:4316])\r
  22         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  23         (Client CN "lapse.rw.madduck.net",\r
  24         Issuer "CAcert Class 3 Root" (verified OK))\r
  25         by clegg.madduck.net (postfix) with ESMTPS id 831CE1D4097;\r
  26         Wed, 13 Jan 2010 02:24:08 +0100 (CET)\r
  27 Received: by lapse.rw.madduck.net (Postfix, from userid 1000)\r
  28         id B93E926E4; Wed, 13 Jan 2010 14:24:04 +1300 (NZDT)\r
  29 Date: Wed, 13 Jan 2010 14:24:04 +1300\r
  30 From: martin f krafft <madduck@madduck.net>\r
  31 To: mailtags discussion list <mailtags@lists.madduck.net>,\r
  32         notmuch discussion list <notmuch@notmuchmail.org>\r
  33 Message-ID: <20100113012404.GA570@lapse.rw.madduck.net>\r
  34 Mail-Followup-To: mailtags discussion list <mailtags@lists.madduck.net>,\r
  35         notmuch discussion list <notmuch@notmuchmail.org>\r
  36 References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  37         <F3C2A2F4-515E-4919-9163-6958C2FAA2C5@indev.ca>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: multipart/signed; micalg=pgp-ripemd160;\r
  40         protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"\r
  41 Content-Disposition: inline\r
  42 In-Reply-To: <F3C2A2F4-515E-4919-9163-6958C2FAA2C5@indev.ca>\r
  43 X-Motto: Keep the good times rollin'\r
  44 X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-trunk-686 i686\r
  45 X-Spamtrap: madduck.bogus@madduck.net\r
  46 X-Subliminal-Message: debian/rules!\r
  47 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  48 X-Virus-Scanned: clamav-milter 0.95.3 at clegg\r
  49 X-Virus-Status: Clean\r
  50 Subject: Re: [notmuch] Idea for storing tags\r
  51 X-BeenThere: notmuch@notmuchmail.org\r
  52 X-Mailman-Version: 2.1.13\r
  53 Precedence: list\r
  54 List-Id: "Use and development of the notmuch mail system."\r
  55         <notmuch.notmuchmail.org>\r
  56 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  58 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  59 List-Post: <mailto:notmuch@notmuchmail.org>\r
  60 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  61 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  62         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  63 X-List-Received-Date: Wed, 13 Jan 2010 01:24:18 -0000\r
  64 \r
  65 \r
  66 --zhXaljGHf11kAtnf\r
  67 Content-Type: text/plain; charset=utf-8\r
  68 Content-Disposition: inline\r
  69 Content-Transfer-Encoding: quoted-printable\r
  70 \r
  71 also sprach Scott Morrison <smorr@indev.ca> [2010.01.12.1711 +1300]:\r
  72 > 1.  synchronization of tag data with emails -- if they are in\r
  73 > a subfolder then it presents the issue of maintaining this\r
  74 > subfolder when managing emails (moving, deleting, duplicating etc)\r
  75 > and any .tag folder unaware clients are likely cause an breakage\r
  76 > in tagdata/message association.  One way of doing this is to have\r
  77 > a global .tag folder.\r
  78 \r
  79 A global .tag folder indexed by e.g. message ID, as you state later,\r
  80 would probably allow for this. Or a file-per-tag design. We'd have\r
  81 to think carefully about pros and cons for each.\r
  82 \r
  83 When thinking about this, I always have to remind myself that we are\r
  84 targetting this at a design that has indexed search. If that weren't\r
  85 the case, searches would be incredibly expensive.\r
  86 \r
  87 Maybe a better approach would be content addressing (see below).\r
  88 \r
  89 > 2. what happens if that message is archived or moved to an\r
  90 > exclusively local cache -- eg. Mail.app on OS X can easily move\r
  91 > IMAP messages to a folder resident on the computers computers?\r
  92 \r
  93 Well, if the target can store tags, then ideally the MUA should know\r
  94 how to transfer them along.\r
  95 \r
  96 Maybe the right thing to do would be to use extended attributes\r
  97 (which are stored in the inode!), even if they may not be\r
  98 universally supported yet. If our solution scales, then this might\r
  99 lead to a significant increase in xattr adoption.\r
 100 \r
 101 > 3. what happens with duplicates of emails -- I would assume that\r
 102 > the message id would be the key to match the tag data to the\r
 103 > message.  In this system a duplicate of a message could not have\r
 104 > a different set of tags from the original (not that this would\r
 105 > necessarily be desirable.)\r
 106 \r
 107 Duplicates need folders, and tags and folders are somewhat at odds\r
 108 with each other. I mean, you can represent a folder hierarchy with\r
 109 tags (and more), and if you have tags and folders, you are\r
 110 potentially introducing a level of confusion/ambiguity that we don't\r
 111 want in the first place. Maybe the ideal solution doesn't need\r
 112 folders anymore (and IMAP-compatible (Maildir) subfolders have\r
 113 always been a hack anyway).\r
 114 \r
 115 There are also two types of duplicates: copies and links. The former\r
 116 can diverge, the latter can't. I don't really see a reason for\r
 117 either. It's not like you need to copy a mail before you edit it,\r
 118 and I don't see a real reason for linking, assuming that the primary\r
 119 means of browsing will be tag-searches anyway.\r
 120 \r
 121 Duplicates always make me think of content addressing, like Git's\r
 122 object cache. We could store the content hash of a message in its\r
 123 filename, and also use the hash to index into the tag database.\r
 124 I think that would be much cleaner than message IDs, and would make\r
 125 handling true duplicates (links) much easier, while copies (diverged\r
 126 ex-duplicates) would also be taken care of automatically.\r
 127 \r
 128 > Your mention of potential leakage (aka inadvertent disclosure of\r
 129 > tag data) is real -- but only if the client used to bounce/forward\r
 130 > is not the one to tag the message (one would assume that if\r
 131 > a client can tag, it can know to exclude the tags in a bounce.)\r
 132 \r
 133 True, and it's probably the minority of people using multiple\r
 134 clients. But those who do might also manipulate mail with sed and\r
 135 use sendmail directly.\r
 136 \r
 137 I don't think we can successfully enhance RFC 5351 to make MTAs\r
 138 always ditch the Tags:-header.\r
 139 \r
 140 > Mail.app -- which I am pluging into does not forward headers --\r
 141 \r
 142 ew! ;) (I think one should be able to forward pristine mails)\r
 143 \r
 144 > though it will include all headers in a bounce -- but chance are\r
 145 > you aren't tagging messages you are bouncing.:)\r
 146 \r
 147 That chance might well be very low. I bounce/forward-as-attachment\r
 148 a lot of mail from the past to make it easier for others to\r
 149 establish context.\r
 150 \r
 151 > The performance issue is very real -- because it means that\r
 152 > somehow messages have to rewritten to the IMAP server -- IMAP\r
 153 > doesn't have a mechanism AFAIK for updates.\r
 154 \r
 155 Not even UIDPLUS?\r
 156 http://wiki.dovecot.org/FeatUIDPLUS\r
 157 \r
 158 > Additionally, IMAP doesn't have a mechanism for simply replacing\r
 159 > one message data with another -- a new message must be written and\r
 160 > the old message must be deleted and the message IMAP UID will\r
 161 > change, and the client will have to deal with this especially if\r
 162 > it is cache the messages.\r
 163 \r
 164 Yes, I am experiencing this pain regularly, since I currently use\r
 165 a lot of message rewriting as part of my workflow =E2=80=94 one of the\r
 166 reasons why I'd like to find an alternative.\r
 167 \r
 168 > Also GMAIL IMAP is an issue-\r
 169 \r
 170 Yeah, I bet. Is there anyone who doesn't think that that's Google's\r
 171 problem, not ours, though?\r
 172 \r
 173 --=20\r
 174 martin | http://madduck.net/ | http://two.sentenc.es/\r
 175 =20\r
 176 "there's someone in my head but it's not me."\r
 177                         -- pink floyd, the dark side of the moon, 1972\r
 178 =20\r
 179 spamtraps: madduck.bogus@madduck.net\r
 180 \r
 181 --zhXaljGHf11kAtnf\r
 182 Content-Type: application/pgp-signature; name="digital_signature_gpg.asc"\r
 183 Content-Description: Digital signature (see http://martin-krafft.net/gpg/)\r
 184 Content-Disposition: inline\r
 185 \r
 186 -----BEGIN PGP SIGNATURE-----\r
 187 Version: GnuPG v1.4.10 (GNU/Linux)\r
 188 \r
 189 iEYEAREDAAYFAktNILQACgkQIgvIgzMMSnXINACcC5HPn9BB6TLpwhMJmfau4Fa1\r
 190 u8YAn0ck+gn4QN6EK1VgnV6IbjpuEJ5B\r
 191 =XeqW\r
 192 -----END PGP SIGNATURE-----\r
 193 \r
 194 --zhXaljGHf11kAtnf--\r