[Top][All Lists]

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

[Nmh-workers] Garbage collection

From: Ken Hornstein
Subject: [Nmh-workers] Garbage collection
Date: Tue, 01 Jan 2013 11:56:41 -0500

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.

- 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 :-)

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

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

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


reply via email to

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