Ken's analysis is right on target. We should pay attention to what people need, first, and how to implement it, second.
And I agree that individual (shell) commands for message operations give MH its real power. The most common resource-intensive operation that I do on my message store is grep, so I currently need messages to be in unencoded flat files. Though that could be replaced by a mhgrep that extracts messages from whatever form they're in and feeds them to grep (and caches due to likely locality of reference). Analogous to what less(1) does with compressed files: it just works. With that, I could live with an IMAP, database, filesystem or other reasonable interface to whatever is used for actual storage. It'd be nice if nmh supported any such interface if provided with a suitable adapter. Could we get there from here? Probably but it would be painful, due to not being designed to support that kind of extension as well as having to support a storied legacy. I'd advocate starting over from scratch, which I think gets back to Norm's point. I was just going to send this when I saw your message about mhcat, Ken. I use this frequently: alias sl='show -nocheckmime -showproc less' David _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
