If such a disaster were to ever happen, the new system should not
be called mh or nmh -- it is too violative of the spirit of mh.
I hope that, in parallel, nmh would continue to grow.
Chris Garrigues <cwg-dated-1028045524(_dot_)7c7f99(_at_)DeepEddy(_dot_)Com>
writes:
--==_Exmh_35284420P
Content-Type: text/plain; charset=us-ascii
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.
--==_Exmh_35284420P--
Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
norm(_at_)dad(_dot_)org