10/b6caf8ba16ed4a8386191897841c20df3b2a7f

   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 170A4431FBC\r
   6         for <notmuch@notmuchmail.org>; Sun, 31 Jan 2010 23:27:37 -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.339\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=2.260,\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 FcU4TshRcrWo for <notmuch@notmuchmail.org>;\r
  16         Sun, 31 Jan 2010 23:27:35 -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 950AB431FAE\r
  19         for <notmuch@notmuchmail.org>; Sun, 31 Jan 2010 23:27:35 -0800 (PST)\r
  20 Received: from lapse.rw.madduck.net (lapse.nz.madduck.net\r
  21         [IPv6:2001:4428:234::1])\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 C27F91D4097\r
  26         for <notmuch@notmuchmail.org>; Mon,  1 Feb 2010 08:27:29 +0100 (CET)\r
  27 Received: by lapse.rw.madduck.net (Postfix, from userid 1000)\r
  28         id 7BE39FF; Mon,  1 Feb 2010 20:27:25 +1300 (NZDT)\r
  29 Date: Mon, 1 Feb 2010 20:27:25 +1300\r
  30 From: martin f krafft <madduck@madduck.net>\r
  31 To: notmuch@notmuchmail.org\r
  32 Message-ID: <20100201072725.GA24716@lapse.rw.madduck.net>\r
  33 Mail-Followup-To: notmuch@notmuchmail.org\r
  34 References: <87wrz3zl94.fsf@gmail.com>\r
  35 MIME-Version: 1.0\r
  36 Content-Type: multipart/signed; micalg=pgp-ripemd160;\r
  37         protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi"\r
  38 Content-Disposition: inline\r
  39 In-Reply-To: <87wrz3zl94.fsf@gmail.com>\r
  40 X-Motto: Keep the good times rollin'\r
  41 X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-trunk-686 i686\r
  42 X-Spamtrap: madduck.bogus@madduck.net\r
  43 X-Subliminal-Message: debian/rules!\r
  44 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  45 X-Virus-Scanned: clamav-milter 0.95.3 at clegg\r
  46 X-Virus-Status: Clean\r
  47 Subject: Re: [notmuch] Some thoughts about notmuch sync with other agents\r
  48 X-BeenThere: notmuch@notmuchmail.org\r
  49 X-Mailman-Version: 2.1.13\r
  50 Precedence: list\r
  51 List-Id: "Use and development of the notmuch mail system."\r
  52         <notmuch.notmuchmail.org>\r
  53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  56 List-Post: <mailto:notmuch@notmuchmail.org>\r
  57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  60 X-List-Received-Date: Mon, 01 Feb 2010 07:27:38 -0000\r
  61 \r
  62 \r
  63 --Qxx1br4bt0+wmkIi\r
  64 Content-Type: text/plain; charset=utf-8\r
  65 Content-Disposition: inline\r
  66 Content-Transfer-Encoding: quoted-printable\r
  67 \r
  68 also sprach Paul R <paul.r.ml@gmail.com> [2010.01.28.0316 +1300]:\r
  69 > As you see, I advocate a NotMuch <-> IMAP synchronisation ASAP :)\r
  70 \r
  71 Given the limitations of IMAP (non-transactional, non-standard\r
  72 keywords implementation, =E2=80=A6), I think chances of this are rapidly\r
  73 diminishing, but I'd love to be proven wrong.\r
  74 \r
  75 > First of all, processing mail with MUA involves some simple logic that\r
  76 > is shared by most MUA. This is about receiving *new* mails, *reading*\r
  77 > mail, *replying* to mail and so on... IMHO, this really belongs to the\r
  78 > mail processing logic and not to the user logic. Hence my first\r
  79 > request :\r
  80 >=20\r
  81 >   1: Don't use user tags space to store MUA flags.\r
  82 >=20\r
  83 >      That means no more "seen", "unread", "replied" as tags. These are\r
  84 >      MUA processing *flags*, that must belong to an established set.\r
  85 >      Tags, on the other hand, are user-land information. So no more\r
  86 >      [seen, replied, grandma, important] tag sets :)\r
  87 \r
  88 I disagree.\r
  89 \r
  90 The MUA actually doesn't (shouldn't) care at all about any of these\r
  91 flags, at least not for core functionality. Sure, a MUA should\r
  92 probably hide messages tagged 'deleted', and it would be nice if it\r
  93 could be configured to highlight messages tagged 'important', but\r
  94 none of the others =E2=80=94 "seen", "unread", "replied", =E2=80=A6 =E2=80=\r
  95 =94 have any role\r
  96 in the core functionality. They are purely user-specific.\r
  97 \r
  98 They are leftovers from days when some MUA designer decided that\r
  99 having these flags would be a useful way to organise e-mail\r
 100 handling, but that person probably dealt with a dozen messages\r
 101 a day, and didn't have half his/her life organised through\r
 102 electronic mail.\r
 103 \r
 104 Point being, times and needs have changed. And while we're in the\r
 105 process of finding the technology that can suit those needs (in the\r
 106 most generic way), we might just as well (and should) rid ourselves\r
 107 =66rom these leftovers.\r
 108 \r
 109 Any solution must be generic enough so that if you rely on the\r
 110 functionality provided by these tags, you can trivially make it\r
 111 happen, e.g. with hooks to add/remove flags on certain actions (such\r
 112 as sending a reply, or reading a message).\r
 113 \r
 114 Neither IMAP nor Maildir is capable of storing an extensible,\r
 115 freely-configurable set of tags (keywords). Therefore, we need a new\r
 116 method anyway.\r
 117 \r
 118 > Once this is done, notmuch will know, in a robust a predictable\r
 119 > way, what happened to a mail. Simply put, NotMuch will store and\r
 120 > expose MUA flags (Passed, Replied, Seen, Trashed, Draft, and\r
 121 > Flagged [1]). For each <flag>, notmuch should associate\r
 122 > a <flag>_synced flag. When changing <flag> from notmuch, it should\r
 123 > set the <flag>_synced bit to 0. These are MUA mail flags.\r
 124 \r
 125 I think the semantics would be clearer the other way around: setting\r
 126 *_changed when a flag is changed.\r
 127 \r
 128 > Additionally, in a third =C2=AB space =C2=BB, notmuch should store its =\r
 129 =C2=AB new =C2=BB\r
 130 > bit, as well as a =C2=AB missing =C2=BB bit probably. Again, this is neit=\r
 131 her MUA\r
 132 > logic or user logic, so this should not interfer with user\r
 133 > classification facility provided by tags, nor with MUA flags. It,\r
 134 > really, is something else, let's name it "status".\r
 135 \r
 136 Or "lifetime".\r
 137 \r
 138 > Once this is done, the 'notmuch new' command should find new mails\r
 139 > and set the 'new' bit for them, and find the missing mails and set\r
 140 > the 'missing' bit for them. This will allow for robust external\r
 141 > processing.\r
 142 \r
 143 Why would I want to keep around a record in the database when the\r
 144 physical file is no longer present?\r
 145 \r
 146 > # 1/ Sync from NotMuch to MailDir\r
 147 >=20\r
 148 >     notmuch list flags:(seen and not seen_synced)=20\r
 149 >       | notmuch-maildir --mark-mail seen\r
 150 >       | notmuch move --stdin\r
 151 >       | notmuch set flags:+seen_synced --stdin\r
 152 \r
 153 Have you seen/look at notmuchsync?\r
 154 \r
 155 > The output of the first command would be a list of filenames for mails\r
 156 > 'seen' since last sync. The second one, an external notmuch--maildir\r
 157 > helper, would propagate this logic to the MailDir store (easy, this is\r
 158 > simply a rename), and output the list of (old-name ! new-name). Then\r
 159 > notmuch would use this information, via a generic 'move' switch, to know\r
 160 > that mail has been moved, and would output the list of the new places.\r
 161 > Finaly, notmuch would set the seen_synced flag.\r
 162 \r
 163 What happens if notmuch-move gets killed due to out-of-memory half\r
 164 way through?\r
 165 \r
 166 > As we have seen, this would allow most IMAP <-> MailDir <-> NotMuch\r
 167 > synchronisation, without having to implement any kind of\r
 168 > MailDir-specific logic inside notmuch.\r
 169 \r
 170 It would not take care of any tags beyond the very strictly defined\r
 171 and limited set of tags you listed in your mail. My point is that we\r
 172 need to solve this problem more generally anyway =E2=80=94 why should\r
 173 a "replied" tag be synchronised, but a "no-need-to-reply" tag not?\r
 174 \r
 175 --=20\r
 176 martin | http://madduck.net/ | http://two.sentenc.es/\r
 177 =20\r
 178 #include <signature.h>\r
 179 =20\r
 180 spamtraps: madduck.bogus@madduck.net\r
 181 \r
 182 --Qxx1br4bt0+wmkIi\r
 183 Content-Type: application/pgp-signature; name="digital_signature_gpg.asc"\r
 184 Content-Description: Digital signature (see http://martin-krafft.net/gpg/)\r
 185 Content-Disposition: inline\r
 186 \r
 187 -----BEGIN PGP SIGNATURE-----\r
 188 Version: GnuPG v1.4.10 (GNU/Linux)\r
 189 \r
 190 iEYEAREDAAYFAktmgloACgkQIgvIgzMMSnW+oACdGPY3MX3eHVOmlWfo+Uisbk8M\r
 191 ah8AnidQCYVnIR58EV00FvXvih0zAXIJ\r
 192 =Qo0I\r
 193 -----END PGP SIGNATURE-----\r
 194 \r
 195 --Qxx1br4bt0+wmkIi--\r