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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers