>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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
