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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers