47/bd1c59cc8d6081831308431cbefdee6f11e10f

   1 Return-Path: <SRS0=X/Ls=HZ=riseup.net=micah@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 1D01C431FBC\r
   6         for <notmuch@notmuchmail.org>; Mon,  7 Dec 2009 15:52:04 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id e+l9QT72WLyh for <notmuch@notmuchmail.org>;\r
  11         Mon,  7 Dec 2009 15:52:03 -0800 (PST)\r
  12 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])\r
  13         by olra.theworths.org (Postfix) with ESMTP id 36C1A431FAE\r
  14         for <notmuch@notmuchmail.org>; Mon,  7 Dec 2009 15:52:03 -0800 (PST)\r
  15 Received-SPF: pass (mxus0: domain of riseup.net designates 204.13.164.18 as\r
  16         permitted sender) client-ip=204.13.164.18;\r
  17         envelope-from=micah@riseup.net; helo=mx1.riseup.net; \r
  18 Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18])\r
  19         by mx.perfora.net (node=mxus0) with ESMTP (Nemesis)\r
  20         id 0LvTlT-1OHdLt2EBH-00zzkK for notmuch@notmuchmail.org;\r
  21         Mon, 07 Dec 2009 18:52:02 -0500\r
  22 Received: from [127.0.0.1] (localhost [127.0.0.1])\r
  23         (Authenticated sender: micah@mx1.riseup.net)\r
  24         with ESMTPSA id 3CA6E25EC0D\r
  25 Received: by lillypad (Postfix, from userid 1000)\r
  26         id 7F5534C0562; Mon,  7 Dec 2009 18:51:59 -0500 (EST)\r
  27 From: micah anderson <micah@riseup.net>\r
  28 To: notmuch <notmuch@notmuchmail.org>\r
  29 In-reply-to: <87638i75sz.fsf@home.veldthuis.com>\r
  30 References: <874oo7hex2.fsf@yoom.home.cworth.org>\r
  31         <87y6lewqtw.fsf@convex-new.cs.unb.ca>\r
  32         <87638i75sz.fsf@home.veldthuis.com>\r
  33 Date: Mon, 07 Dec 2009 18:51:58 -0500\r
  34 Message-Id: <1260227209-sup-184@riseup.net>\r
  35 User-Agent: Sup/0.9\r
  36 Content-Transfer-Encoding: 8bit\r
  37 Content-Type: multipart/signed; micalg="pgp-sha1";\r
  38         boundary="=-1260229919-169652-2819-9554-13-=";\r
  39         protocol="application/pgp-signature"\r
  40 MIME-Version: 1.0\r
  41 X-Virus-Scanned: clamav-milter 0.95.2 at mx1\r
  42 X-Virus-Status: Clean\r
  43 Subject: Re: [notmuch] Quick thoughts on a notmuch daemon\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.12\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48         <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Mon, 07 Dec 2009 23:52:04 -0000\r
  57 \r
  58 \r
  59 --=-1260229919-169652-2819-9554-13-=\r
  60 Content-Type: text/plain; charset=UTF-8\r
  61 \r
  62 Excerpts from Marten Veldthuis's message of Mon Dec 07 17:55:24 -0500 2009:\r
  63 > On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner <david@tethera.net> wrote:\r
  64 > > \r
  65 > > On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth <cworth@cworth.org> wrote:\r
  66 > > It might be a bit blue sky, but if this daemon could (optionally) talk\r
  67 > > IMAP and translate tags into folders on the fly, this would be very\r
  68 > > useful for people who need imap access to their mail as well as from an\r
  69 > > custom notmuch client.\r
  70 > \r
  71 > For me, my IMAP needs are pretty much limited to my iPhone. I'm making\r
  72 > do for now, but to make notmuch viable in the long term, what I'd need\r
  73 > is:\r
  74 > \r
  75 >  * notmuch shouldn't choke on mails I had in notmuch's database, and\r
  76 >    then marked read or deleted on my iPhone (which renames them in the\r
  77 >    maildir). This is coming with the moving/deleting patches.\r
  78 >  * notmuch should sync back read/unread state to maildir\r
  79 >  * notmuch should move read stuff out of my inbox. It would be\r
  80 >    acceptable if it moved everything into a designated archive folder\r
  81 >    unless it had the 'inbox' tag assigned, in which case it moved it\r
  82 >    there. Note that we have the moving/deleting patches, then this could\r
  83 >    even be done as a script and some searches.\r
  84 > \r
  85 > With this, my inbox would be usable from my iPhone.\r
  86 \r
  87 I dont have an iPhone, but this would be a *killer* feature for me, and\r
  88 I suspect for others as well. \r
  89 \r
  90 I have two fundamental problems with label-state clients (sup, notmuch)\r
  91 that I am still trying to come to terms with, this bluesky feature would\r
  92 change that radically.\r
  93 \r
  94 The first issue is that I do not have unlimited IMAP storage space on\r
  95 the server, in fact I have a quota. I know, lots of people have\r
  96 effectively unlimited space,and others POP/fetchmail things so its not\r
  97 stored on the server...but lots of us still do have upper limits that we\r
  98 have to deal with and many of us do use IMAP, for good reasons. With\r
  99 label-state clients (sup, notmuch) you have to accept the fact that your\r
 100 mail is going to grow on the IMAP server indefinitely. This is not a\r
 101 good thing for those of us with quotas, but it is also a bad thing for\r
 102 some IMAP servers who choke to death on very large IMAP stores (or\r
 103 consume an awful lot of memory dealing with them). Or you have to setup\r
 104 kludgy archive operations to periodically deal with the disk space\r
 105 issue.\r
 106 \r
 107 The second mind-bending problem is that sometimes I actually do have to\r
 108 use mutt, sometimes webmail (for various reasons, but one important one\r
 109 in the early stages of a new email client is that notmuch just doesn't\r
 110 have support for certain operations such as inline/pgp-mime handling of\r
 111 emails, which means I need to open those emails in other clients that do\r
 112 support that). Other people likely are going to need to use things like\r
 113 iphones or blackberries. Indeed, using other clients is not an\r
 114 unreasonable thing for people to do. However, switching between notmuch\r
 115 and these clients is. Because the message state is stored in a DB which\r
 116 is only useful for notmuch, its a dreadful nightmare to do anything\r
 117 outside of the notmuch world.\r
 118 \r
 119 Most importantly, having all of your email state in a notmuch database\r
 120 format means that it can only be parsed by those tools, and is no longer\r
 121 in a standard format. I think it is great that 'notmuch restore' can\r
 122 deal with the sup database format, which may signal the dawn of a new\r
 123 label-state standard....but still the problem is the glue to the\r
 124 underlying maildir structure which provides a lot of useful information\r
 125 contained in reasonably well-defined ways is totally thrown out the\r
 126 window. \r
 127 \r
 128 I've switched mail clients enough over the past few years to know that\r
 129 switching itself is a major pain. I've settled on Maildir as my storage\r
 130 method of choice and in a way it is a 'client'. I can serve it via IMAP\r
 131 if I need, I can read it with different mail clients and maintain state\r
 132 across those mail clients, there are tools to manipulate and convert\r
 133 maildirs that have matured over the years. If I switch to an\r
 134 'all-in-one' label-state mail client, like notmuch, I want to be sure\r
 135 that in 2 years from now if I happen to decide to change to something\r
 136 else (I'm hoping this wont EVER happen because notmuch is very\r
 137 promising, but I need to be honest based on past experiences here), then\r
 138 I'm going to want to make sure that all of my mail is marked as read,\r
 139 deleted mail is deleted and even though I was using labels for\r
 140 organizational purposes in notmuch, things are still organized in some\r
 141 way appropriate to folders on the filesystem.\r
 142 \r
 143 The way it is now, if I switch to notmuch and then try to switch back,\r
 144 my life is a total mess because all of the state is contained within the\r
 145 notmuch database, that is frightening for the long-term, but it also\r
 146 makes me very worried about simple corruption of that data store. If I\r
 147 lose that state, I'm totally screwed. At least in a maildir scenario, if\r
 148 I got corruption in one place it might cause me to lose one email, but\r
 149 if I get corruption in my notmuch database, I had better have a recent\r
 150 backup or I am screwed. \r
 151 \r
 152 The important part is gluing the maildir capabilities in there, and not\r
 153 getting distracted by the transport (let offlineimap and its ilk handle\r
 154 this, maybe some eager python hacker might find a way to add this to\r
 155 offlineimap?!).\r
 156 \r
 157 I like to think that this concept of label-state, indexable\r
 158 storage-backed mail clients is the dawn of a new age, just as maildir\r
 159 was to mbox, but I'm still scared because there is no mb2md equivalent\r
 160 yet.\r
 161 \r
 162 micah\r
 163 \r
 164 --=-1260229919-169652-2819-9554-13-=\r
 165 Content-Disposition: attachment; filename="signature.asc"\r
 166 Content-Type: application/pgp-signature; name="signature.asc"\r
 167 \r
 168 -----BEGIN PGP SIGNATURE-----\r
 169 Version: GnuPG v1.4.10 (GNU/Linux)\r
 170 \r
 171 iQIcBAEBCgAGBQJLHZUeAAoJEIy/mjIoYaeQbq0QAJdlU9/UVzP4KHRkvYt28BC8\r
 172 hV9KTPIVpR0bngusnkYeNIAzQjol2FKQCVvpn6pUGfGGAkd4yBWfb5LsirhuYWLt\r
 173 sC5XVEP55Fe03ezu/56VA4dxMmP2n9ysBrkcFmSgzWXnmsw7/yG/oYl4bm4iNB6L\r
 174 hyEQIxMuJxNBxw7wzKftcBlC+pbsMdbNxKxqcK8SMxsY/1nGzTnxCTloJef6Ist1\r
 175 dEm2UKZP0jVl3YFmVoevnS2UP4xdFmHK/+tY/XLKiZKo3xmQEyGyq3TccYXb27/c\r
 176 cCervy7BXwwjCNbpBez6Hbb2v7l0RpdsIUl0lLdr1uMMOvoSK3rLXBgUeKWYvDS8\r
 177 KAJZQ4Icns4gpDFv3PcK6eTPkxv2FEQCSSHfju0g84+zh62+TFBngoXpkQLetfU+\r
 178 d+bhcnvq8BDn2uCh+73Vz0g7zPd7qU+u3Sw5ZP1jm69Op5LwuikQ+qQea2XRpBds\r
 179 ofhNcxQvjupF94JgBoQjbJgby4M8S8+a0dgWqMx1685YY2QeQWgoj+wwQHC9zUqM\r
 180 v8WheiNQVh4X+PRCCe2meEA+Amc1cTT4lbmDRM7lqrBrjqft3BwRNPET3n/Boa9T\r
 181 pQwebhpsC6wZ8cFBvEox8CLIpyMrrWZMxcfrcwdUZQwzOBcA7qPJx96ZRR2iXCC5\r
 182 xuNNtiFyV4Czu9d/Txaa\r
 183 =TAmp\r
 184 -----END PGP SIGNATURE-----\r
 185 \r
 186 --=-1260229919-169652-2819-9554-13-=--\r