Re: [Nmh-workers] Holiday hacking project: nmh?

[Harald Geyer]

Hi!

> However.  I encounter bugs in mh that no-one seems
> to want to acknowledge or want to fix.  Also I strongly
> suspect that many security bugs lie within the ancient mh
> code, and the attitude of many is apathy.
 
I don't believe this is true. There are many caring about nmh. Enough
people would volunteer for fixing bugs etc. but unfortunately nobody
is ready to take over release management as Ken has suggested. (requested?)

Also note: Yes there are security relevant bugs. ATM they don't get fixed
in CVS, but they get fixed by the distributors. If security is an issue,
use a version for which there is security support. E.g. Debian provides
the most recent nmh+fixes.

> My own little attempt to help give nmh a little nudge
> (the suggestion of a distributed version control system)
> was not met with enthusiasm.

Well I don't believe, this can replace somebody doing the coordination,
but others have elaborated on that already...

> However(2) on a more positive note ...  What would make a nice
> addition to nmh is a test suite; for example an mbox of problematical,
> possibly not standards compliant mail that nonetheless
> you would expect nmh to cope with or at least spit
> out an informative error or warning message.

I have no need as I get enough problematical mails every time ;-), but
if you have some good idea you probably should make the start. I guess
you wouldn't need ongoing nmh development, would you?

> My own pie in the sky thoughts would be towards replacing
> some of the code with some better tested or more widely
> used mail handling code, (librfc822 ? (1)) and also possible
> partial conversion to c++.

Yes nmh does some things in a very weird way. Sometimes this is out of
reason. Sometimes it should be changed. Much of this could be done by
moving to standard functions, which are available on every supported
environment anyway. However using specialized libraries such as 
librfc822 is quite difficult if not impossible out of several reasons
(incomplete list ;)):

* This libraries are often no available on all systems nmh tries to
  support.
* Many like nmh for being quite small. (Measured in Bytes/feature)
* Changing everthing to new functions might be more work, than
  bringing nmh's own functions into good shape.
* The libraries might not be legally compatible with nmh.
* The libraries licenses might not be compatible with the authors
  and former authors attitude to free software.

Also I don't see any need to change to c++ (reimplement it?) besides
the availability of nice libs (which most likely could be reimplemented
in c with less trouble).

Harald