Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>As for IMAP on the back end, forget it.  MH cannot deal with immutable
>message files.  It just won't fly.  I looked at using the various IMAP
>annotate extensions, but the bottom line is the code would have to work
>with a plain old 3501-compliant IMAP server.  It can't.  And even with
>IMAP annotation support on the server, the n! conglomeration of IMAP
>extensions your have to deal with these days leads to an n! explosion in
>the complexity of the MH library.  That way lies madness.

The fact that a) GNU Mailutils exists and b) claims to support an IMAP
backend would suggest to me one of two things:

1) GNU Mailutils doesn't really work as well as people say it does when
   you combine the MH tools and the IMAP backend
2) It is possible, for some definition of "working" to combine the two.

Now, it may be that it's just too complicated; I was only talking about
the current MH API.  You know more about IMAP than I do, that much is
obvious, but surprising thing that has been made clear to me based
on recent discussions is that a number of people are happy to accept
some weakening of MH functionality if they get some gains in return.
For example, some front-ends basically make user-defined sequences
useless, and they don't support annotations either.  Yet people are
perfectly happy to use those front-ends.  Those are the two biggest
issues with having the MH programs use an IMAP store.  If you relax
those requirements things are much easier.

>Keep MH simple.  If you want IMAP, you know where to find it.  And if
>you know both IMAP and MH, you know when and where to apply each of
>them.

The problem I see is that if you have a requirement that your mailboxes
live on IMAP, then that means you have to switch away from nmh.  That's
unfortunate (it's also the reason given as for why MIT no longer supports
nmh, and I know we have a number of ex-MITers on this list).

--Ken