nmh-workers
[Top] [All Lists]

Re: nmh and tcl

2002-07-25 11:18:34
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


<Prev in Thread] Current Thread [Next in Thread>