c6/8a24d529d634bc492fb3ecae679a90e5c70664

   1 Return-Path: <smorr@indev.ca>\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 C544F431FBC\r
   6         for <notmuch@notmuchmail.org>; Tue, 12 Jan 2010 21:39:17 -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.295\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[AWL=2.894, \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 Bt5MCGplHliv for <notmuch@notmuchmail.org>;\r
  16         Tue, 12 Jan 2010 21:39:16 -0800 (PST)\r
  17 X-Greylist: delayed 91652 seconds by postgrey-1.32 at olra;\r
  18         Tue, 12 Jan 2010 21:39:16 PST\r
  19 Received: from homiemail-a5.g.dreamhost.com (caiajhbdccac.dreamhost.com\r
  20         [208.97.132.202])\r
  21         by olra.theworths.org (Postfix) with ESMTP id C7EB2431FAE\r
  22         for <notmuch@notmuchmail.org>; Tue, 12 Jan 2010 21:39:16 -0800 (PST)\r
  23 Received: from [192.168.2.199] (modemcable049.81-81-70.mc.videotron.ca\r
  24         [70.81.81.49])\r
  25         by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 8AA24BC9D5;\r
  26         Tue, 12 Jan 2010 21:39:15 -0800 (PST)\r
  27 References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  28         <F3C2A2F4-515E-4919-9163-6958C2FAA2C5@indev.ca>\r
  29         <20100113012404.GA570@lapse.rw.madduck.net>\r
  30 In-Reply-To: <20100113012404.GA570@lapse.rw.madduck.net>\r
  31 Mime-Version: 1.0 (Apple Message framework v1077)\r
  32 Content-Type: text/plain; charset=windows-1252\r
  33 Message-Id: <BF51FFFB-41D1-4105-84AA-43C3FEB8365D@indev.ca>\r
  34 Content-Transfer-Encoding: quoted-printable\r
  35 From: Scott Morrison <smorr@indev.ca>\r
  36 Date: Wed, 13 Jan 2010 00:39:14 -0500\r
  37 To: mailtags discussion list <mailtags@lists.madduck.net>\r
  38 X-Mailer: Apple Mail (2.1077)\r
  39 Cc: notmuch discussion list <notmuch@notmuchmail.org>\r
  40 Subject: Re: [notmuch] Idea for storing tags\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Wed, 13 Jan 2010 05:39:17 -0000\r
  54 \r
  55 \r
  56 On 2010-01-12, at 8:24 PM, martin f krafft wrote:\r
  57 \r
  58 > also sprach Scott Morrison <smorr@indev.ca> [2010.01.12.1711 +1300]:\r
  59 >> 1.  synchronization of tag data with emails -- if they are in\r
  60 >> a subfolder then it presents the issue of maintaining this\r
  61 >> subfolder when managing emails (moving, deleting, duplicating etc)\r
  62 >> and any .tag folder unaware clients are likely cause an breakage\r
  63 >> in tagdata/message association.  One way of doing this is to have\r
  64 >> a global .tag folder.\r
  65 >=20\r
  66 > A global .tag folder indexed by e.g. message ID, as you state later,\r
  67 > would probably allow for this. Or a file-per-tag design. We'd have\r
  68 > to think carefully about pros and cons for each.\r
  69 >=20\r
  70 > When thinking about this, I always have to remind myself that we are\r
  71 > targetting this at a design that has indexed search. If that weren't\r
  72 > the case, searches would be incredibly expensive.\r
  73 >=20\r
  74 > Maybe a better approach would be content addressing (see below).\r
  75 \r
  76 \r
  77 Content hashing -- good Idea (& not something that has hit me before) -- =\r
  78 better than Message-Id as I believe there are still some MUA /MTAs that =\r
  79 allow messages without message ids.  The only potential issue with this =\r
  80 is that it is critical then to preserve the message source against =\r
  81 encoding changes though that shouldn't be too hard to avoid.\r
  82 \r
  83 >=20\r
  84 >> 2. what happens if that message is archived or moved to an\r
  85 >> exclusively local cache -- eg. Mail.app on OS X can easily move\r
  86 >> IMAP messages to a folder resident on the computers computers?\r
  87 >=20\r
  88 > Well, if the target can store tags, then ideally the MUA should know\r
  89 > how to transfer them along.\r
  90 >=20\r
  91 > Maybe the right thing to do would be to use extended attributes\r
  92 > (which are stored in the inode!), even if they may not be\r
  93 > universally supported yet. If our solution scales, then this might\r
  94 > lead to a significant increase in xattr adoption.\r
  95 The problem with anything that is not universally supported is that for =\r
  96 a package that is to appeal to a wide userbase, most don't know and =\r
  97 don't care about the particulars of this IMAP server vs that IMAP =\r
  98 server.  all they know it that for some reason it doesn't work with =\r
  99 account X -- which leads to support head aches.\r
 100 \r
 101 >=20\r
 102 >> 3. what happens with duplicates of emails -- I would assume that\r
 103 >> the message id would be the key to match the tag data to the\r
 104 >> message.  In this system a duplicate of a message could not have\r
 105 >> a different set of tags from the original (not that this would\r
 106 >> necessarily be desirable.)\r
 107 >=20\r
 108 > Duplicates need folders, and tags and folders are somewhat at odds\r
 109 > with each other. I mean, you can represent a folder hierarchy with\r
 110 > tags (and more), and if you have tags and folders, you are\r
 111 > potentially introducing a level of confusion/ambiguity that we don't\r
 112 > want in the first place. Maybe the ideal solution doesn't need\r
 113 > folders anymore (and IMAP-compatible (Maildir) subfolders have\r
 114 > always been a hack anyway).\r
 115 >=20\r
 116 > There are also two types of duplicates: copies and links. The former\r
 117 > can diverge, the latter can't. I don't really see a reason for\r
 118 > either. It's not like you need to copy a mail before you edit it,\r
 119 > and I don't see a real reason for linking, assuming that the primary\r
 120 > means of browsing will be tag-searches anyway.\r
 121 >=20\r
 122 > Duplicates always make me think of content addressing, like Git's\r
 123 > object cache. We could store the content hash of a message in its\r
 124 > filename, and also use the hash to index into the tag database.\r
 125 > I think that would be much cleaner than message IDs, and would make\r
 126 > handling true duplicates (links) much easier, while copies (diverged\r
 127 > ex-duplicates) would also be taken care of automatically.\r
 128 \r
 129 I agree that conceptually duplicates should be buried but end users do =\r
 130 have "peculiar" organization systems.\r
 131 \r
 132 >=20\r
 133 > -snip-\r
 134 \r
 135 >> The performance issue is very real -- because it means that\r
 136 >> somehow messages have to rewritten to the IMAP server -- IMAP\r
 137 >> doesn't have a mechanism AFAIK for updates.\r
 138 >=20\r
 139 > Not even UIDPLUS?\r
 140 > http://wiki.dovecot.org/FeatUIDPLUS\r
 141 =46rom my reading, uidplus doesn't allow a delta modification of a =\r
 142 message on a server -- just to write a portion of a message back -- you =\r
 143 still have to write the whole thing back and that can mean real =\r
 144 bandwidth issues for some messages.\r
 145 \r
 146 >=20\r
 147 >> Additionally, IMAP doesn't have a mechanism for simply replacing\r
 148 >> one message data with another -- a new message must be written and\r
 149 >> the old message must be deleted and the message IMAP UID will\r
 150 >> change, and the client will have to deal with this especially if\r
 151 >> it is cache the messages.\r
 152 >=20\r
 153 > Yes, I am experiencing this pain regularly, since I currently use\r
 154 > a lot of message rewriting as part of my workflow =97 one of the\r
 155 > reasons why I'd like to find an alternative.\r
 156 >=20\r
 157 >> Also GMAIL IMAP is an issue-\r
 158 >=20\r
 159 > Yeah, I bet. Is there anyone who doesn't think that that's Google's\r
 160 > problem, not ours, though?\r
 161 >=20\r
 162 Call it Googles problem as you like -- but when I have a product that =\r
 163 doesn't work with GMAIL IMAP there are a lot of potential users that =\r
 164 don't care about server peculiarities and rather just have it work.\r
 165 \r
 166 \r