Hoi, thanks for letting the discussion cool down.
There are times to question your basic assumptions, and there are times to not do that. If you permanently question your basic assumptions, then you move nowhere. When I started with mmh, I did question everything, which was good at that time, but then I set my priorities and estimated the effort-outcome-ratio to decided which assumptions to take and which ones to throw over. One of the decisions that enabled me (and later us) to move well forward, was accepting MH as the storage backend. It is not perfect but it is not horrible either. It is one of a bunch of alternatives, all with their pros and cons. One big advantage of the MH format was that it was already implemented and that we knew that it worked. Thus the effort could go directly into (in my eyes) more important areas. This is what we have done: We moved forward. We refined mmh by sharpening the concepts and refining the overall shape. If I try to remember using nmh in 2010, that's really hard to do, because in the meanwhile so many improvements where achieved which feed all too natural today. Take the draft and trash folders! Or the attachment system! And equally, replacing m_getfld()! These were big steps. And there are more structural improvements to come. One is the unifying of the folder/msg and dirpath/file handling on the command line. The other is the rework of whatnow(1) and draft management in general. (These are my main goals for the next release.) Furthermore, I am awaiting the results of the IMAP sync project, which is hoped to provide us with a follow-this-howto-and-you'll-have-mmh-with-imap-support setup. I guess, if we would have started with replacing the storage backend, then we would still be stuck in that phase, or mmh would have died already. (Have you read ``Dreaming in Code''?) And as I said already, there are other projects that do this much better. In contrast to other possible achievements in mmh, the storage backend is good enough currently, I think. Other fields offer much better effort-outcome-ratios. Nonetheless, there will come a time, when asking the storage backend question will be important again, but I don't feel that this time would be now. If your goal is to have the most productive MUA, I'd rather suggest mutt to you. If you search for mmh with more features, then go to nmh. I don't want mmh be all that. Mmh is a MUA for lovers of the Unix philosophy. It is for people who accept to sacrifice for the beauty within. Mmh is an experiment and a demonstration, and it tries to be an MH-like mail client just like I want to have it. If you share my taste in these things, then mmh probably is a wonderful project for you, as well. If you don't, you might become more happy somewhere else. meillo
