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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
