--- /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 170A4431FBC\r
+ for <notmuch@notmuchmail.org>; Sun, 31 Jan 2010 23:27:37 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.339\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=2.260,\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 FcU4TshRcrWo for <notmuch@notmuchmail.org>;\r
+ Sun, 31 Jan 2010 23:27:35 -0800 (PST)\r
+Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96])\r
+ by olra.theworths.org (Postfix) with ESMTP id 950AB431FAE\r
+ for <notmuch@notmuchmail.org>; Sun, 31 Jan 2010 23:27:35 -0800 (PST)\r
+Received: from lapse.rw.madduck.net (lapse.nz.madduck.net\r
+ [IPv6:2001:4428:234::1])\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 C27F91D4097\r
+ for <notmuch@notmuchmail.org>; Mon, 1 Feb 2010 08:27:29 +0100 (CET)\r
+Received: by lapse.rw.madduck.net (Postfix, from userid 1000)\r
+ id 7BE39FF; Mon, 1 Feb 2010 20:27:25 +1300 (NZDT)\r
+Date: Mon, 1 Feb 2010 20:27:25 +1300\r
+From: martin f krafft <madduck@madduck.net>\r
+To: notmuch@notmuchmail.org\r
+Message-ID: <20100201072725.GA24716@lapse.rw.madduck.net>\r
+Mail-Followup-To: notmuch@notmuchmail.org\r
+References: <87wrz3zl94.fsf@gmail.com>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; micalg=pgp-ripemd160;\r
+ protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi"\r
+Content-Disposition: inline\r
+In-Reply-To: <87wrz3zl94.fsf@gmail.com>\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] Some thoughts about notmuch sync with other agents\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: Mon, 01 Feb 2010 07:27:38 -0000\r
+\r
+\r
+--Qxx1br4bt0+wmkIi\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+also sprach Paul R <paul.r.ml@gmail.com> [2010.01.28.0316 +1300]:\r
+> As you see, I advocate a NotMuch <-> IMAP synchronisation ASAP :)\r
+\r
+Given the limitations of IMAP (non-transactional, non-standard\r
+keywords implementation, =E2=80=A6), I think chances of this are rapidly\r
+diminishing, but I'd love to be proven wrong.\r
+\r
+> First of all, processing mail with MUA involves some simple logic that\r
+> is shared by most MUA. This is about receiving *new* mails, *reading*\r
+> mail, *replying* to mail and so on... IMHO, this really belongs to the\r
+> mail processing logic and not to the user logic. Hence my first\r
+> request :\r
+>=20\r
+> 1: Don't use user tags space to store MUA flags.\r
+>=20\r
+> That means no more "seen", "unread", "replied" as tags. These are\r
+> MUA processing *flags*, that must belong to an established set.\r
+> Tags, on the other hand, are user-land information. So no more\r
+> [seen, replied, grandma, important] tag sets :)\r
+\r
+I disagree.\r
+\r
+The MUA actually doesn't (shouldn't) care at all about any of these\r
+flags, at least not for core functionality. Sure, a MUA should\r
+probably hide messages tagged 'deleted', and it would be nice if it\r
+could be configured to highlight messages tagged 'important', but\r
+none of the others =E2=80=94 "seen", "unread", "replied", =E2=80=A6 =E2=80=\r
+=94 have any role\r
+in the core functionality. They are purely user-specific.\r
+\r
+They are leftovers from days when some MUA designer decided that\r
+having these flags would be a useful way to organise e-mail\r
+handling, but that person probably dealt with a dozen messages\r
+a day, and didn't have half his/her life organised through\r
+electronic mail.\r
+\r
+Point being, times and needs have changed. And while we're in the\r
+process of finding the technology that can suit those needs (in the\r
+most generic way), we might just as well (and should) rid ourselves\r
+=66rom these leftovers.\r
+\r
+Any solution must be generic enough so that if you rely on the\r
+functionality provided by these tags, you can trivially make it\r
+happen, e.g. with hooks to add/remove flags on certain actions (such\r
+as sending a reply, or reading a message).\r
+\r
+Neither IMAP nor Maildir is capable of storing an extensible,\r
+freely-configurable set of tags (keywords). Therefore, we need a new\r
+method anyway.\r
+\r
+> Once this is done, notmuch will know, in a robust a predictable\r
+> way, what happened to a mail. Simply put, NotMuch will store and\r
+> expose MUA flags (Passed, Replied, Seen, Trashed, Draft, and\r
+> Flagged [1]). For each <flag>, notmuch should associate\r
+> a <flag>_synced flag. When changing <flag> from notmuch, it should\r
+> set the <flag>_synced bit to 0. These are MUA mail flags.\r
+\r
+I think the semantics would be clearer the other way around: setting\r
+*_changed when a flag is changed.\r
+\r
+> Additionally, in a third =C2=AB space =C2=BB, notmuch should store its =\r
+=C2=AB new =C2=BB\r
+> bit, as well as a =C2=AB missing =C2=BB bit probably. Again, this is neit=\r
+her MUA\r
+> logic or user logic, so this should not interfer with user\r
+> classification facility provided by tags, nor with MUA flags. It,\r
+> really, is something else, let's name it "status".\r
+\r
+Or "lifetime".\r
+\r
+> Once this is done, the 'notmuch new' command should find new mails\r
+> and set the 'new' bit for them, and find the missing mails and set\r
+> the 'missing' bit for them. This will allow for robust external\r
+> processing.\r
+\r
+Why would I want to keep around a record in the database when the\r
+physical file is no longer present?\r
+\r
+> # 1/ Sync from NotMuch to MailDir\r
+>=20\r
+> notmuch list flags:(seen and not seen_synced)=20\r
+> | notmuch-maildir --mark-mail seen\r
+> | notmuch move --stdin\r
+> | notmuch set flags:+seen_synced --stdin\r
+\r
+Have you seen/look at notmuchsync?\r
+\r
+> The output of the first command would be a list of filenames for mails\r
+> 'seen' since last sync. The second one, an external notmuch--maildir\r
+> helper, would propagate this logic to the MailDir store (easy, this is\r
+> simply a rename), and output the list of (old-name ! new-name). Then\r
+> notmuch would use this information, via a generic 'move' switch, to know\r
+> that mail has been moved, and would output the list of the new places.\r
+> Finaly, notmuch would set the seen_synced flag.\r
+\r
+What happens if notmuch-move gets killed due to out-of-memory half\r
+way through?\r
+\r
+> As we have seen, this would allow most IMAP <-> MailDir <-> NotMuch\r
+> synchronisation, without having to implement any kind of\r
+> MailDir-specific logic inside notmuch.\r
+\r
+It would not take care of any tags beyond the very strictly defined\r
+and limited set of tags you listed in your mail. My point is that we\r
+need to solve this problem more generally anyway =E2=80=94 why should\r
+a "replied" tag be synchronised, but a "no-need-to-reply" tag not?\r
+\r
+--=20\r
+martin | http://madduck.net/ | http://two.sentenc.es/\r
+=20\r
+#include <signature.h>\r
+=20\r
+spamtraps: madduck.bogus@madduck.net\r
+\r
+--Qxx1br4bt0+wmkIi\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
+iEYEAREDAAYFAktmgloACgkQIgvIgzMMSnW+oACdGPY3MX3eHVOmlWfo+Uisbk8M\r
+ah8AnidQCYVnIR58EV00FvXvih0zAXIJ\r
+=Qo0I\r
+-----END PGP SIGNATURE-----\r
+\r
+--Qxx1br4bt0+wmkIi--\r
projects / notmuch-archives.git / commitdiff