Re: [Nmh-workers] Garbage collection

[Bill Wohler]

Ken Hornstein <address@hidden> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD