--- /dev/null
+Return-Path: <madduck@lapse.rw.madduck.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 0BF8E431FBC\r
+ for <notmuch@notmuchmail.org>; Tue, 12 Jan 2010 17:24:18 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.232\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=2.367,\r
+ BAYES_00=-2.599] autolearn=ham\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id URU-XxsN2AFi for <notmuch@notmuchmail.org>;\r
+ Tue, 12 Jan 2010 17:24:17 -0800 (PST)\r
+Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96])\r
+ by olra.theworths.org (Postfix) with ESMTP id AF440431FAE\r
+ for <notmuch@notmuchmail.org>; Tue, 12 Jan 2010 17:24:16 -0800 (PST)\r
+Received: from lapse.rw.madduck.net (unknown\r
+ [IPv6:2404:130:0:1000:20a:e4ff:fe30:4316])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (Client CN "lapse.rw.madduck.net",\r
+ Issuer "CAcert Class 3 Root" (verified OK))\r
+ by clegg.madduck.net (postfix) with ESMTPS id 831CE1D4097;\r
+ Wed, 13 Jan 2010 02:24:08 +0100 (CET)\r
+Received: by lapse.rw.madduck.net (Postfix, from userid 1000)\r
+ id B93E926E4; Wed, 13 Jan 2010 14:24:04 +1300 (NZDT)\r
+Date: Wed, 13 Jan 2010 14:24:04 +1300\r
+From: martin f krafft <madduck@madduck.net>\r
+To: mailtags discussion list <mailtags@lists.madduck.net>,\r
+ notmuch discussion list <notmuch@notmuchmail.org>\r
+Message-ID: <20100113012404.GA570@lapse.rw.madduck.net>\r
+Mail-Followup-To: mailtags discussion list <mailtags@lists.madduck.net>,\r
+ notmuch discussion list <notmuch@notmuchmail.org>\r
+References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
+ <F3C2A2F4-515E-4919-9163-6958C2FAA2C5@indev.ca>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; micalg=pgp-ripemd160;\r
+ protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"\r
+Content-Disposition: inline\r
+In-Reply-To: <F3C2A2F4-515E-4919-9163-6958C2FAA2C5@indev.ca>\r
+X-Motto: Keep the good times rollin'\r
+X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-trunk-686 i686\r
+X-Spamtrap: madduck.bogus@madduck.net\r
+X-Subliminal-Message: debian/rules!\r
+User-Agent: Mutt/1.5.20 (2009-06-14)\r
+X-Virus-Scanned: clamav-milter 0.95.3 at clegg\r
+X-Virus-Status: Clean\r
+Subject: Re: [notmuch] Idea for storing tags\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 13 Jan 2010 01:24:18 -0000\r
+\r
+\r
+--zhXaljGHf11kAtnf\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+also sprach Scott Morrison <smorr@indev.ca> [2010.01.12.1711 +1300]:\r
+> 1. synchronization of tag data with emails -- if they are in\r
+> a subfolder then it presents the issue of maintaining this\r
+> subfolder when managing emails (moving, deleting, duplicating etc)\r
+> and any .tag folder unaware clients are likely cause an breakage\r
+> in tagdata/message association. One way of doing this is to have\r
+> a global .tag folder.\r
+\r
+A global .tag folder indexed by e.g. message ID, as you state later,\r
+would probably allow for this. Or a file-per-tag design. We'd have\r
+to think carefully about pros and cons for each.\r
+\r
+When thinking about this, I always have to remind myself that we are\r
+targetting this at a design that has indexed search. If that weren't\r
+the case, searches would be incredibly expensive.\r
+\r
+Maybe a better approach would be content addressing (see below).\r
+\r
+> 2. what happens if that message is archived or moved to an\r
+> exclusively local cache -- eg. Mail.app on OS X can easily move\r
+> IMAP messages to a folder resident on the computers computers?\r
+\r
+Well, if the target can store tags, then ideally the MUA should know\r
+how to transfer them along.\r
+\r
+Maybe the right thing to do would be to use extended attributes\r
+(which are stored in the inode!), even if they may not be\r
+universally supported yet. If our solution scales, then this might\r
+lead to a significant increase in xattr adoption.\r
+\r
+> 3. what happens with duplicates of emails -- I would assume that\r
+> the message id would be the key to match the tag data to the\r
+> message. In this system a duplicate of a message could not have\r
+> a different set of tags from the original (not that this would\r
+> necessarily be desirable.)\r
+\r
+Duplicates need folders, and tags and folders are somewhat at odds\r
+with each other. I mean, you can represent a folder hierarchy with\r
+tags (and more), and if you have tags and folders, you are\r
+potentially introducing a level of confusion/ambiguity that we don't\r
+want in the first place. Maybe the ideal solution doesn't need\r
+folders anymore (and IMAP-compatible (Maildir) subfolders have\r
+always been a hack anyway).\r
+\r
+There are also two types of duplicates: copies and links. The former\r
+can diverge, the latter can't. I don't really see a reason for\r
+either. It's not like you need to copy a mail before you edit it,\r
+and I don't see a real reason for linking, assuming that the primary\r
+means of browsing will be tag-searches anyway.\r
+\r
+Duplicates always make me think of content addressing, like Git's\r
+object cache. We could store the content hash of a message in its\r
+filename, and also use the hash to index into the tag database.\r
+I think that would be much cleaner than message IDs, and would make\r
+handling true duplicates (links) much easier, while copies (diverged\r
+ex-duplicates) would also be taken care of automatically.\r
+\r
+> Your mention of potential leakage (aka inadvertent disclosure of\r
+> tag data) is real -- but only if the client used to bounce/forward\r
+> is not the one to tag the message (one would assume that if\r
+> a client can tag, it can know to exclude the tags in a bounce.)\r
+\r
+True, and it's probably the minority of people using multiple\r
+clients. But those who do might also manipulate mail with sed and\r
+use sendmail directly.\r
+\r
+I don't think we can successfully enhance RFC 5351 to make MTAs\r
+always ditch the Tags:-header.\r
+\r
+> Mail.app -- which I am pluging into does not forward headers --\r
+\r
+ew! ;) (I think one should be able to forward pristine mails)\r
+\r
+> though it will include all headers in a bounce -- but chance are\r
+> you aren't tagging messages you are bouncing.:)\r
+\r
+That chance might well be very low. I bounce/forward-as-attachment\r
+a lot of mail from the past to make it easier for others to\r
+establish context.\r
+\r
+> The performance issue is very real -- because it means that\r
+> somehow messages have to rewritten to the IMAP server -- IMAP\r
+> doesn't have a mechanism AFAIK for updates.\r
+\r
+Not even UIDPLUS?\r
+http://wiki.dovecot.org/FeatUIDPLUS\r
+\r
+> Additionally, IMAP doesn't have a mechanism for simply replacing\r
+> one message data with another -- a new message must be written and\r
+> the old message must be deleted and the message IMAP UID will\r
+> change, and the client will have to deal with this especially if\r
+> it is cache the messages.\r
+\r
+Yes, I am experiencing this pain regularly, since I currently use\r
+a lot of message rewriting as part of my workflow =E2=80=94 one of the\r
+reasons why I'd like to find an alternative.\r
+\r
+> Also GMAIL IMAP is an issue-\r
+\r
+Yeah, I bet. Is there anyone who doesn't think that that's Google's\r
+problem, not ours, though?\r
+\r
+--=20\r
+martin | http://madduck.net/ | http://two.sentenc.es/\r
+=20\r
+"there's someone in my head but it's not me."\r
+ -- pink floyd, the dark side of the moon, 1972\r
+=20\r
+spamtraps: madduck.bogus@madduck.net\r
+\r
+--zhXaljGHf11kAtnf\r
+Content-Type: application/pgp-signature; name="digital_signature_gpg.asc"\r
+Content-Description: Digital signature (see http://martin-krafft.net/gpg/)\r
+Content-Disposition: inline\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iEYEAREDAAYFAktNILQACgkQIgvIgzMMSnXINACcC5HPn9BB6TLpwhMJmfau4Fa1\r
+u8YAn0ck+gn4QN6EK1VgnV6IbjpuEJ5B\r
+=XeqW\r
+-----END PGP SIGNATURE-----\r
+\r
+--zhXaljGHf11kAtnf--\r
projects / notmuch-archives.git / commitdiff