Re: [Nmh-workers] Garbage collection

[Bill Wohler]

Note that we are discussing removing orthogonal programs from MH only to
clarify the focus of the program and to simply the build environment. We
are not discussing killing anything. If there is still interest, it
would be easy enough to package these items separately.

Mike O'Dell <address@hidden> writes:

> 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.
>
>     cheers,
>     -mo
>
>
>
> 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.
>> 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
>>>
>
>
> _______________________________________________
> 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