I had some thoughts about bringing nmh into the 21st century which is quite
likely
to provoke some discussion:
An IMAP back end will require a *lot* more state to be maintained between
nmh commands in order to get any reasonable performance.
MH was written as a collection of related commands rather than a single
executable for two reasons:
a) So you could intermix MH commands with whatever else you're doing.
b) To make it easy to use MH commands programmatically.
More recently, the strategy that applications have used to implement (b) is to
embed a language such as tcl instead.
If nmh were to include an mhsh which was tclsh with nmh commands, the state
could be maintained in the shell instead of having to write everything out to
temp files.
exmh is written in tk/tcl.
If nmh were to include an wimhsh (wimsh? mhwish?) which was wish with nmh
commands, exmh could use that shell instead of wish and call the commands
directly, gaining considerable performance.
The existing separate executables would remain for backwards compatibility,
but accessing an imap server would be slow because of the need to snapshot
state and establish and tear down the connection. Since you can run commands
from within tclsh or wish, for performance, you'd just run mhsh in any session
where you wanted to read mail and run the commands there.
I don't have the C skills to implement this myself, but I'd be willing to work
with others in figuring out what the tcl version of nmh commands would look
like, if different than the shell versions, and I'd be willing to reimplement
exmh to use the new shell.
--
Chris Garrigues http://www.DeepEddy.Com/~cwg/
virCIO http://www.virCIO.Com
716 Congress, Suite 200
Austin, TX 78701 +1 512 374 0500
World War III: The Wrong-Doers Vs. the Evil-Doers.
pgpxGZQf1UROw.pgp
Description: PGP signature