Ken Hornstein <kenh(_at_)pobox(_dot_)com> writes:
Greetings all,
I'm been thinking about Markus's master's thesis, and it's motivated me to
remove some old crud sitting around in nmh. I'd like to get some feedback
about it.
I've started reading it too, and thus far I do not have any objections
to the clean-ups.
- Remove ALL the traces of UUCP support. I'm assuming that the only
response
here will be, "nmh still has UUCP support?". Well, it kinda does, but
it's been bitrotting for a long time. I want to remove EVERYTHING that
has "uucp" in the name. FWIW, I see that the UUCP Mapping project
officially shut down in November of 2000 (I'm honestly surprised that
it lasted that long). Also, it looks like to me that no RFC describes
how UUCP addresses are supposed to be formatted, so it's not even clear
to me how a correct address parser are supposed to handle those things.
Agreed.
- Remove dbm/ndbm dependency. The ONLY reason nmh has a dependency on
a db library is for duplicate suppression in slocal; if slocal finds
a duplicate Message-ID, it discards it. I didn't think getting a dbm
library was so hard, but apparantly it is under Linux; the autoconf
stuff for this is a giant mess. I'm wondering ... do people actually
use this functionality? I'm thinking the days of using slocal in
your .forward file have slowly been coming to an end. At the very least
we should make this functionality optional ... that would make things
easier for Paul Fox, if no one else :-)
I use duplicate message suppression, but I use procmail to do that.
I think Markus suggests that we remove the orthogonal slocal program
entirely. I have to agree since I've been using procmail for years, and
may switch to sieve in the future. We can easily create a separate
slocal project for the slocal die-hards and remove an unused portion of
MH (for many of us).
- Remove rcvtty completely. This works in conjunction with slocal or
procmail; it broadcasts new message summaries to your terminal. Because
of OpenBSD unpleasantness it's challenging to get it working there, and
it really occurs to me that it's the wrong thing to be doing.
Agreed. It is also orthogonal to the MH UI and is provided by other
methods. If there is still support out there, we can split off another
project.
- Content-MD5 support. I will admit that I haven't done a complete survey,
but from what I've seen nmh is the only MUA still generating a
Content-MD5
header in MIME messages. This means we need a MD5 implementation, and
a test for it. This has caused portability problems in the past, and
I'm wondering if this is useful at all; I get the feeling that we're the
only ones to support it. See Markus's thesis for a more complete survey.
$ grep -i content-md5 mh-e/*.el
$
Agreed.
- EBCDIC safe encoding. Forces quoted-printable encoding if an "EBCDIC
unsafe" character is seen (see uip/mhbuildsbr.c:ebcdicsafe[]). We
don't care about this, right?
Agreed.
Happy New Year, everyone!
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers