[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Garbage collection

From: Mike O'Dell
Subject: Re: [Nmh-workers] Garbage collection
Date: Fri, 04 Jan 2013 14:56:07 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0

I still use "slocal" because it does what I need easily and simply.

"procmail" is hardly a poster child for great software
UI design or implementation, and I would look very
dimly upon the prospect of re-implementing a
many-hundred-line .maildelivery file as the goo
required by "procmail".

as for the assertion that "it's OK to kill-off slocal because the
capability can be supplied by some other program",
that assertion applies with equal validity to the entirety of nmh.


On 1/4/13 2:30 PM, Bill Wohler wrote:
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.

- 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

- 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


- 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?

Happy New Year, everyone!


Nmh-workers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]