c0/8a3befc4bbafa43f814280d3768fa0d734c169

   1 Return-Path: <SRS0=a4S0=JM=plane.gmane.org=public@srs.perfora.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 C4B6B431FBC\r
   6         for <notmuch@notmuchmail.org>; Wed, 27 Jan 2010 06:16:28 -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.001\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.001 tagged_above=-999 required=5\r
  12         tests=[BAYES_50=0.001] 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 n+87boE0Yp5n for <notmuch@notmuchmail.org>;\r
  16         Wed, 27 Jan 2010 06:16:27 -0800 (PST)\r
  17 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])\r
  18         by olra.theworths.org (Postfix) with ESMTP id D24E4431FAE\r
  19         for <notmuch@notmuchmail.org>; Wed, 27 Jan 2010 06:16:27 -0800 (PST)\r
  20 Received-SPF: pass (mxus1: domain of plane.gmane.org designates 80.91.229.3 as\r
  21         permitted sender) client-ip=80.91.229.3;\r
  22         envelope-from=public@plane.gmane.org; helo=plane.gmane.org; \r
  23 Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])\r
  24         by mx.perfora.net (node=mxus1) with ESMTP (Nemesis)\r
  25         id 0LewLP-1O9FFF1ZXz-00q87P for notmuch@notmuchmail.org;\r
  26         Wed, 27 Jan 2010 09:16:26 -0500\r
  27 Received: from public by plane.gmane.org with local (Exim 4.63)\r
  28         (envelope-from <public@plane.gmane.org>) id 1Na8gk-0006h3-In\r
  29         for notmuch@notmuchmail.org; Wed, 27 Jan 2010 15:16:10 +0100\r
  30 Received: from mail-ew0-f224.google.com ([209.85.219.224])\r
  31         by plane.gmane.org with esmtp (Exim 4.63)\r
  32         (envelope-from <paul.r.ml@gmail.com>) id 1Na8gf-0006e8-F2\r
  33         for public-notmuch-gxuj+Tv9EO5zyzON3hdc1g@plane.gmane.org;\r
  34         Wed, 27 Jan 2010 15:16:05 +0100\r
  35 Received: by ewy24 with SMTP id 24so1147591ewy.26\r
  36         for <notmuch-gxuj+Tv9EO5zyzON3hdc1g@public.gmane.org>;\r
  37         Wed, 27 Jan 2010 06:16:11 -0800 (PST)\r
  38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  39         h=domainkey-signature:received:received:from:to:subject:date\r
  40         :message-id:user-agent:mime-version:content-type\r
  41         :content-transfer-encoding;\r
  42         bh=3zfT1AGMFeWwOGcjt07ZYxPE99oKFWRWkJypL7mkJRY=;\r
  43         b=He/zQ4KjCWjNU8d7bVTWZMGAaAaKdikRSQemR8EM6VZe9G97KkyUd/TgDRxECBAvi2\r
  44         vDPxAScvO+cv4njU+wWVqYsE8hapxVjrs9DB+dqjx+OGF5hzUJtkXgva5sqL5B+dm1l4\r
  45         GetysWU9XgF4qPJevOq0b5mPBMwwzaxeJ0HbU=\r
  46 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  47         h=from:to:subject:date:message-id:user-agent:mime-version\r
  48         :content-type:content-transfer-encoding;\r
  49         b=JbzDQW7Vh8TW0NmGjx2yq3VYVDUlx6rc81AKsIScsd0bn6ZnoIMBhXqSFWEIbDLUZA\r
  50         oyypGEhJTHs0WHUtAMr7B5pmDiF/9fU9V7kF1k81s3SHAF5SpS0IWJtwBUxmj7aMCK68\r
  51         zE2ivGAaILxmV0UfK5kSlElhXwJgR8FpatlGM=\r
  52 Received: by 10.213.1.18 with SMTP id 18mr2552002ebd.17.1264601770650;\r
  53         Wed, 27 Jan 2010 06:16:10 -0800 (PST)\r
  54 Received: from ubuT42 (vil35-2-82-227-204-220.fbx.proxad.net [82.227.204.220])\r
  55         by mx.google.com with ESMTPS id 13sm5982192ewy.1.2010.01.27.06.16.09\r
  56         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  57         Wed, 27 Jan 2010 06:16:09 -0800 (PST)\r
  58 From: Paul R <paul.r.ml@gmail.com>\r
  59 To: notmuch <public-notmuch-gxuj+Tv9EO5zyzON3hdc1g@plane.gmane.org>\r
  60 Date: Wed, 27 Jan 2010 15:16:07 +0100\r
  61 Message-ID: <87wrz3zl94.fsf@gmail.com>\r
  62 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)\r
  63 MIME-Version: 1.0\r
  64 Content-Type: text/plain; charset=utf-8\r
  65 Content-Transfer-Encoding: quoted-printable\r
  66 X-Mailman-Approved-At: Fri, 29 Jan 2010 16:40:03 -0800\r
  67 Subject: [notmuch] Some thoughts about notmuch sync with other agents\r
  68 X-BeenThere: notmuch@notmuchmail.org\r
  69 X-Mailman-Version: 2.1.13\r
  70 Precedence: list\r
  71 List-Id: "Use and development of the notmuch mail system."\r
  72         <notmuch.notmuchmail.org>\r
  73 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  75 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  76 List-Post: <mailto:notmuch@notmuchmail.org>\r
  77 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  78 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  79         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  80 X-List-Received-Date: Wed, 27 Jan 2010 14:16:28 -0000\r
  81 \r
  82 \r
  83 \r
  84 Hi,\r
  85 \r
  86 before going into details, I'd like to tell you how much I like the\r
  87 notmuch workflow, thank you for producing this nice piece of software !\r
  88 \r
  89 Like most potential users, I can not really fully jump into notmuch\r
  90 because of the current synchronisation issues with others MUA. One may\r
  91 or may not like IMAP for good reasons, the fact is that it is here and\r
  92 has allowed users to read mails from various places and terminals,\r
  93 keeping important information synced. So I think that notmuch will have\r
  94 to live with that, and provide what is required to integrate smoothly\r
  95 into this environment. Redefining a new mail retrieval protocol and\r
  96 a mail storing format are both really exciting projects, but they are\r
  97 projects on their own that could only distract notmuch from its most\r
  98 beautiful goal : giving *today* users the power to process mail in an\r
  99 efficient way.\r
 100 \r
 101 As you see, I advocate a NotMuch <-> IMAP synchronisation ASAP :)\r
 102 \r
 103 At the moment, notmuch input are mail-as-file + user-defined tags.\r
 104 OfflineIMAP allows to do the IMAP <-> mail-as-file transition, in both\r
 105 directions, mail-as-file being namely MailDir. So we can simply aim at\r
 106 a NotMuch <-> MailDir synchronisation, offlineimap will take care of\r
 107 IMAP itself.\r
 108 \r
 109 Of course, my proposal does not require to implement any MailDir\r
 110 specific logic inside NotMuch, but rather describes how should notmuch\r
 111 evolve to allow easy third-party-tool jobs.\r
 112 \r
 113 \r
 114 Preliminary thoughts :\r
 115 ----------------------\r
 116 \r
 117 First of all, processing mail with MUA involves some simple logic that\r
 118 is shared by most MUA. This is about receiving *new* mails, *reading*\r
 119 mail, *replying* to mail and so on... IMHO, this really belongs to the\r
 120 mail processing logic and not to the user logic. Hence my first\r
 121 request :\r
 122 \r
 123   1: Don't use user tags space to store MUA flags.\r
 124 \r
 125      That means no more "seen", "unread", "replied" as tags. These are\r
 126      MUA processing *flags*, that must belong to an established set.\r
 127      Tags, on the other hand, are user-land information. So no more\r
 128      [seen, replied, grandma, important] tag sets :)\r
 129 \r
 130 Once this is done, notmuch will know, in a robust a predictable way,\r
 131 what happened to a mail. Simply put, NotMuch will store and expose MUA\r
 132 flags (Passed, Replied, Seen, Trashed, Draft, and Flagged [1]). For each\r
 133 <flag>, notmuch should associate a <flag>_synced flag. When changing\r
 134 <flag> from notmuch, it should set the <flag>_synced bit to 0. These are\r
 135 MUA mail flags.\r
 136 \r
 137 Additionally, in a third =C2=AB space =C2=BB, notmuch should store its =C2=\r
 138 =AB new =C2=BB\r
 139 bit, as well as a =C2=AB missing =C2=BB bit probably. Again, this is neithe=\r
 140 r MUA\r
 141 logic or user logic, so this should not interfer with user\r
 142 classification facility provided by tags, nor with MUA flags. It,\r
 143 really, is something else, let's name it "status". Once this is done,\r
 144 the 'notmuch new' command should find new mails and set the 'new' bit\r
 145 for them, and find the missing mails and set the 'missing' bit for them.\r
 146 This will allow for robust external processing.\r
 147 \r
 148 Finally, notmuch should provide a switch to output a list of filenames\r
 149 to stdout and to process a list of filenames from stdin.\r
 150 \r
 151 \r
 152 NotMuch <-> MailDir synchronisation :\r
 153 -------------------------------------\r
 154 \r
 155 Provided the behaviour described above, notmuch <-> MailDir\r
 156 synchronisation could be done fully externally, by a 'notmuch-maildir'\r
 157 adapter.\r
 158 \r
 159 Here is some pseudo code, that could be wrapped into a single\r
 160 'notmuch-sync' command. The | are unix stream pipes, and everything\r
 161 should be on a single line.\r
 162 \r
 163 # 1/ Sync from NotMuch to MailDir\r
 164 \r
 165     notmuch list flags:(seen and not seen_synced)=20\r
 166       | notmuch-maildir --mark-mail seen\r
 167       | notmuch move --stdin\r
 168       | notmuch set flags:+seen_synced --stdin\r
 169 \r
 170 The output of the first command would be a list of filenames for mails\r
 171 'seen' since last sync. The second one, an external notmuch--maildir\r
 172 helper, would propagate this logic to the MailDir store (easy, this is\r
 173 simply a rename), and output the list of (old-name ! new-name). Then\r
 174 notmuch would use this information, via a generic 'move' switch, to know\r
 175 that mail has been moved, and would output the list of the new places.\r
 176 Finaly, notmuch would set the seen_synced flag.\r
 177 \r
 178 Same would apply for the Replied, Trashed, Flagged and Passed flags.\r
 179 \r
 180 # 2/ Then lets do the MailDir <-> IMAP sync\r
 181 \r
 182      offlineimap\r
 183 \r
 184 ... done ! that was easy :)\r
 185 \r
 186 # 3/ notmuch new\r
 187 \r
 188      notmuch new\r
 189 \r
 190 At this point, notmuch should set the 'new' or the 'missing' status bit\r
 191 to the mails. Let's forget how to deal with the missing bit, that should\r
 192 be easy to do.\r
 193 \r
 194 # 4/ Sync from MailDir to NotMuch\r
 195 \r
 196   notmuch list status:new=20\r
 197    | notmuch-maildir --filter seen\r
 198    | notmuch set flags:+seen+seen_synced --stdin\r
 199 \r
 200 First command outputs newly discovered mail. Second one reads stdin and\r
 201 output only files that are already seen (again, this is as easy as\r
 202 a filter based on a regular expression). Third one reads stdin and\r
 203 applies the seen and seen_synced flags.\r
 204 \r
 205 Same applies for the Replied, Trashed, Flagged and Passed flags.\r
 206 \r
 207 \r
 208 Conclusion:\r
 209 -----------\r
 210 \r
 211 As we have seen, this would allow most IMAP <-> MailDir <-> NotMuch\r
 212 synchronisation, without having to implement any kind of\r
 213 MailDir-specific logic inside notmuch. In fact, this notmuch-maildir\r
 214 helper would be a simple script, and we could imagine doing similar\r
 215 script for other stores, without having to touch the core of notmuch.\r
 216 \r
 217 \r
 218 That was a long mail indeed, thank you for reading ! I'm waiting for\r
 219 your comments.\r
 220 \r
 221 \r
 222 \r
 223 Footnotes:=20\r
 224 [1]  http://cr.yp.to/proto/maildir.html\r
 225 \r
 226 --=20\r
 227   Paul\r
 228 \r