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