1 Return-Path: <cworth@cworth.org>
\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 BE5E7431FBF;
\r
6 Mon, 7 Dec 2009 23:01:41 -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 OQL5-gsO1ejf; Mon, 7 Dec 2009 23:01:40 -0800 (PST)
\r
11 Received: from yoom.home.cworth.org (localhost [127.0.0.1])
\r
12 by olra.theworths.org (Postfix) with ESMTP id 1D424431FAE;
\r
13 Mon, 7 Dec 2009 23:01:40 -0800 (PST)
\r
14 Received: by yoom.home.cworth.org (Postfix, from userid 1000)
\r
15 id B4B942542FB; Mon, 7 Dec 2009 23:01:39 -0800 (PST)
\r
16 From: Carl Worth <cworth@cworth.org>
\r
17 To: micah anderson <micah@riseup.net>, notmuch <notmuch@notmuchmail.org>
\r
18 In-Reply-To: <1260227209-sup-184@riseup.net>
\r
19 References: <874oo7hex2.fsf@yoom.home.cworth.org>
\r
20 <87y6lewqtw.fsf@convex-new.cs.unb.ca>
\r
21 <87638i75sz.fsf@home.veldthuis.com> <1260227209-sup-184@riseup.net>
\r
22 Date: Mon, 07 Dec 2009 23:01:32 -0800
\r
23 Message-ID: <874oo22blf.fsf@yoom.home.cworth.org>
\r
25 Content-Type: multipart/signed; boundary="=-=-=";
\r
26 micalg=pgp-sha1; protocol="application/pgp-signature"
\r
27 Subject: Re: [notmuch] Quick thoughts on a notmuch daemon
\r
28 X-BeenThere: notmuch@notmuchmail.org
\r
29 X-Mailman-Version: 2.1.12
\r
31 List-Id: "Use and development of the notmuch mail system."
\r
32 <notmuch.notmuchmail.org>
\r
33 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
34 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
35 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
36 List-Post: <mailto:notmuch@notmuchmail.org>
\r
37 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
38 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
39 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
40 X-List-Received-Date: Tue, 08 Dec 2009 07:01:42 -0000
\r
43 Content-Transfer-Encoding: quoted-printable
\r
45 On Mon, 07 Dec 2009 18:51:58 -0500, micah anderson <micah@riseup.net> wrote:
\r
46 > I've switched mail clients enough over the past few years to know that
\r
47 > switching itself is a major pain.
\r
51 One concept in notmuch (compared to sup) is to (eventually) avoid people
\r
52 having to go through that pain by their current mail client becoming
\r
53 "notmuch enabled". For me, I had always liked composing email in emacs,
\r
54 so I just have to add notmuch support to the existing emacs
\r
57 Hopefully people working on other email interfaces will do similar
\r
58 things, (would be great to have Anjal and Thunderbird get some notmuch
\r
59 support for example).
\r
61 I definitely didn't like that with sup, to get all the global-search and
\r
62 tagging features one had to accept the curses UI as well.
\r
65 > 'all-in-one' label-state mail client, like notmuch, I want to be sure
\r
66 > that in 2 years from now if I happen to decide to change to something
\r
67 > else (I'm hoping this wont EVER happen because notmuch is very
\r
68 > promising, but I need to be honest based on past experiences here), then
\r
69 > I'm going to want to make sure that all of my mail is marked as read,
\r
70 > deleted mail is deleted and even though I was using labels for
\r
71 > organizational purposes in notmuch, things are still organized in some
\r
72 > way appropriate to folders on the filesystem.
\r
74 I appreciate your caution before making the commitment to a mail
\r
75 client. I think that's very wise. [*]
\r
77 And I think that for the case of "I'm giving up on notmuch and want to
\r
78 switch to something else" you can be quite assured that notmuch will
\r
79 allow you to take care of everything you need. At a system level, it's
\r
80 really an almost trivial matter to implement everything you describe
\r
81 above as small shell scripts based on "notmuch search" commands. And I
\r
82 can only imagine support for that kind of thing getting better all the
\r
85 > The way it is now, if I switch to notmuch and then try to switch back,
\r
86 > my life is a total mess because all of the state is contained within the
\r
87 > notmuch database, that is frightening for the long-term, but it also
\r
88 > makes me very worried about simple corruption of that data store. If I
\r
89 > lose that state, I'm totally screwed. At least in a maildir scenario, if
\r
90 > I got corruption in one place it might cause me to lose one email, but
\r
91 > if I get corruption in my notmuch database, I had better have a recent
\r
92 > backup or I am screwed.=20
\r
94 I highly recommend making very regular backups of the output of "notmuch
\r
95 dump". It's a quick process to run, and the file it creates is not
\r
96 large. It's also nicely sorted so that if you are doing some kind of
\r
97 incremental backup, that should work well.
\r
99 > I like to think that this concept of label-state, indexable
\r
100 > storage-backed mail clients is the dawn of a new age, just as maildir
\r
101 > was to mbox, but I'm still scared because there is no mb2md equivalent
\r
104 I think we're really close to where you could write a notmuch2md script
\r
105 as a very tiny shell script:
\r
107 for tag in $(notmuch search --for=3Dtags *); do
\r
108 notmuch search --for=3Dmessages --output=3Dmaildir:/some/dir/$tag tag:$tag
\r
111 Being able to do that kind of scriptable output is pretty powerful. And
\r
112 we're not missing anything fundamental in the system to be able to
\r
113 support that, (just a little bit of support for the new command-line
\r
114 options like --for and --output).
\r
118 [*] I know I went through a similarly cautious evaluation when switching
\r
119 away from CVS. CVS made the transition away so painful that I was
\r
120 determined to choose a system that satisfied me on two criteria:
\r
122 1. The system seemed well-designed enough that I could imagine it
\r
123 surviving "forever".
\r
125 2. That when realities exceeded my imagination, the system wouldn't make
\r
126 it hard for me to switch away.
\r
128 So far I'm still quite happy with git on both points.
\r
131 Content-Type: application/pgp-signature
\r
133 -----BEGIN PGP SIGNATURE-----
\r
134 Version: GnuPG v1.4.10 (GNU/Linux)
\r
136 iD8DBQFLHfnM6JDdNq8qSWgRAta9AJ0cmagTkxvSl7CgpfZrKH9LgOEkMgCdGfx+
\r
137 pROr1MpfuBBq/q1+/BXVuSg=
\r
139 -----END PGP SIGNATURE-----
\r
projects / notmuch-archives.git / blob