[Top][All Lists]

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

Re: [Nmh-workers] cleaning out the cobwebs

From: Peter Maydell
Subject: Re: [Nmh-workers] cleaning out the cobwebs
Date: Wed, 03 Nov 2010 19:53:21 +0000

Jon Steinhart wrote:
>> While reading much nmh code these days, I also feel that parts of the
>> code are ancient. I'd like to support any effort in renewing it.
>> Autoconf is something I dislike.
>I suppose that I'm willing to do some work here too if I'm not alone.  My main
>interest, which I expressed years ago, is to figure out what sbr/m_getfld.c is
>really doing and rewrite it so that I can add additional functionality without
>breaking anything.

I'm not entirely sure what you mean by this. Yes, m_getfld is an
incomprehensible piece of code. Yes, it really shouldn't be digging into
libc internals in the 21st century. Yes, it has optimisation decisions made
based on "what is fastest on my VAX?". But that has nothing to do with
implementing better handling of attachments, nicer MIME capabilities or
anything else. m_getfld() has a very simple purpose: it lets you read
headers and message bodies out of an RFC-822-style text file. You don't need
to care about the internals unless they're actually buggy (and I don't know
about any current bugs, though I did fix one or two a few years back). It
doesn't need any new features because MIME doesn't change the format of
RFC-822 messages, it just adds new things piggybacking on top, which the
caller of m_getfld will eventually need to parse.

Any attempt to rewrite or replace it ought to be preceded by the buildup
of the kind of test suite mentioned in the comments in m_getfld.c and
subsequently (alas) lost to history. (Some of the code in test/tests/inc
is trying to make a start on that.) But if you just want to make nmh's
handling of MIME or attachments better or improve its UI, you don't need
to spend time doing anything with m_getfld anyway.

-- PMM

reply via email to

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