Received-SPF: pass (mxus0: domain of riseup.net designates 204.13.164.18 as
	permitted sender) client-ip=204.13.164.18;
	envelope-from=micah@riseup.net; helo=mx1.riseup.net; 
From: micah anderson <micah@riseup.net>
To: notmuch <notmuch@notmuchmail.org>
In-reply-to: <87638i75sz.fsf@home.veldthuis.com>
References: <874oo7hex2.fsf@yoom.home.cworth.org>
	<87y6lewqtw.fsf@convex-new.cs.unb.ca>
	<87638i75sz.fsf@home.veldthuis.com>
Date: Mon, 07 Dec 2009 18:51:58 -0500
Message-Id: <1260227209-sup-184@riseup.net>
User-Agent: Sup/0.9
Content-Transfer-Encoding: 8bit
Content-Type: multipart/signed; micalg="pgp-sha1";
	boundary="=-1260229919-169652-2819-9554-13-=";
	protocol="application/pgp-signature"
MIME-Version: 1.0
Subject: Re: [notmuch] Quick thoughts on a notmuch daemon
Precedence: list


--=-1260229919-169652-2819-9554-13-=
Content-Type: text/plain; charset=UTF-8

Excerpts from Marten Veldthuis's message of Mon Dec 07 17:55:24 -0500 2009:
> On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner <david@tethera.net> wrote:
> > 
> > On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth <cworth@cworth.org> wrote:
> > It might be a bit blue sky, but if this daemon could (optionally) talk
> > IMAP and translate tags into folders on the fly, this would be very
> > useful for people who need imap access to their mail as well as from an
> > custom notmuch client.
> 
> For me, my IMAP needs are pretty much limited to my iPhone. I'm making
> do for now, but to make notmuch viable in the long term, what I'd need
> is:
> 
>  * notmuch shouldn't choke on mails I had in notmuch's database, and
>    then marked read or deleted on my iPhone (which renames them in the
>    maildir). This is coming with the moving/deleting patches.
>  * notmuch should sync back read/unread state to maildir
>  * notmuch should move read stuff out of my inbox. It would be
>    acceptable if it moved everything into a designated archive folder
>    unless it had the 'inbox' tag assigned, in which case it moved it
>    there. Note that we have the moving/deleting patches, then this could
>    even be done as a script and some searches.
> 
> With this, my inbox would be usable from my iPhone.

I dont have an iPhone, but this would be a *killer* feature for me, and
I suspect for others as well. 

I have two fundamental problems with label-state clients (sup, notmuch)
that I am still trying to come to terms with, this bluesky feature would
change that radically.

The first issue is that I do not have unlimited IMAP storage space on
the server, in fact I have a quota. I know, lots of people have
effectively unlimited space,and others POP/fetchmail things so its not
stored on the server...but lots of us still do have upper limits that we
have to deal with and many of us do use IMAP, for good reasons. With
label-state clients (sup, notmuch) you have to accept the fact that your
mail is going to grow on the IMAP server indefinitely. This is not a
good thing for those of us with quotas, but it is also a bad thing for
some IMAP servers who choke to death on very large IMAP stores (or
consume an awful lot of memory dealing with them). Or you have to setup
kludgy archive operations to periodically deal with the disk space
issue.

The second mind-bending problem is that sometimes I actually do have to
use mutt, sometimes webmail (for various reasons, but one important one
in the early stages of a new email client is that notmuch just doesn't
have support for certain operations such as inline/pgp-mime handling of
emails, which means I need to open those emails in other clients that do
support that). Other people likely are going to need to use things like
iphones or blackberries. Indeed, using other clients is not an
unreasonable thing for people to do. However, switching between notmuch
and these clients is. Because the message state is stored in a DB which
is only useful for notmuch, its a dreadful nightmare to do anything
outside of the notmuch world.

Most importantly, having all of your email state in a notmuch database
format means that it can only be parsed by those tools, and is no longer
in a standard format. I think it is great that 'notmuch restore' can
deal with the sup database format, which may signal the dawn of a new
label-state standard....but still the problem is the glue to the
underlying maildir structure which provides a lot of useful information
contained in reasonably well-defined ways is totally thrown out the
window. 

I've switched mail clients enough over the past few years to know that
switching itself is a major pain. I've settled on Maildir as my storage
method of choice and in a way it is a 'client'. I can serve it via IMAP
if I need, I can read it with different mail clients and maintain state
across those mail clients, there are tools to manipulate and convert
maildirs that have matured over the years. If I switch to an
'all-in-one' label-state mail client, like notmuch, I want to be sure
that in 2 years from now if I happen to decide to change to something
else (I'm hoping this wont EVER happen because notmuch is very
promising, but I need to be honest based on past experiences here), then
I'm going to want to make sure that all of my mail is marked as read,
deleted mail is deleted and even though I was using labels for
organizational purposes in notmuch, things are still organized in some
way appropriate to folders on the filesystem.

The way it is now, if I switch to notmuch and then try to switch back,
my life is a total mess because all of the state is contained within the
notmuch database, that is frightening for the long-term, but it also
makes me very worried about simple corruption of that data store. If I
lose that state, I'm totally screwed. At least in a maildir scenario, if
I got corruption in one place it might cause me to lose one email, but
if I get corruption in my notmuch database, I had better have a recent
backup or I am screwed. 

The important part is gluing the maildir capabilities in there, and not
getting distracted by the transport (let offlineimap and its ilk handle
this, maybe some eager python hacker might find a way to add this to
offlineimap?!).

I like to think that this concept of label-state, indexable
storage-backed mail clients is the dawn of a new age, just as maildir
was to mbox, but I'm still scared because there is no mb2md equivalent
yet.

micah

--=-1260229919-169652-2819-9554-13-=
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJLHZUeAAoJEIy/mjIoYaeQbq0QAJdlU9/UVzP4KHRkvYt28BC8
hV9KTPIVpR0bngusnkYeNIAzQjol2FKQCVvpn6pUGfGGAkd4yBWfb5LsirhuYWLt
sC5XVEP55Fe03ezu/56VA4dxMmP2n9ysBrkcFmSgzWXnmsw7/yG/oYl4bm4iNB6L
hyEQIxMuJxNBxw7wzKftcBlC+pbsMdbNxKxqcK8SMxsY/1nGzTnxCTloJef6Ist1
dEm2UKZP0jVl3YFmVoevnS2UP4xdFmHK/+tY/XLKiZKo3xmQEyGyq3TccYXb27/c
cCervy7BXwwjCNbpBez6Hbb2v7l0RpdsIUl0lLdr1uMMOvoSK3rLXBgUeKWYvDS8
KAJZQ4Icns4gpDFv3PcK6eTPkxv2FEQCSSHfju0g84+zh62+TFBngoXpkQLetfU+
d+bhcnvq8BDn2uCh+73Vz0g7zPd7qU+u3Sw5ZP1jm69Op5LwuikQ+qQea2XRpBds
ofhNcxQvjupF94JgBoQjbJgby4M8S8+a0dgWqMx1685YY2QeQWgoj+wwQHC9zUqM
v8WheiNQVh4X+PRCCe2meEA+Amc1cTT4lbmDRM7lqrBrjqft3BwRNPET3n/Boa9T
pQwebhpsC6wZ8cFBvEox8CLIpyMrrWZMxcfrcwdUZQwzOBcA7qPJx96ZRR2iXCC5
xuNNtiFyV4Czu9d/Txaa
=TAmp
-----END PGP SIGNATURE-----

--=-1260229919-169652-2819-9554-13-=--