Re: [Nmh-workers] The curse of m_getfld()

[Paul Vixie]

On Wed, 25 Jan 2012 22:40:58 -0500
Ken Hornstein <address@hidden> wrote:

...
> Here's my thinking: the bulk of MIME parsing and translation _has_
> to happen in m_getfld().  So in the New World Order, m_getfld()
> reads in a message off of disk, translates anything necessary into
> UTF-8, does things like RFC-2047 header parsing, base-64 &
> quoted-printable decoding, and returns UTF-8 strings to the calling
> functions.

i don't think you're cutting deep enough. nmh is simply not that big;
we can afford an internal api change to get away from the m_getfld
monolith. we don't need to add mime as a layer; we need to change the
underlying data structures to be mime-cognizant, and make accessing
them and iterating over them abstract operations.

...
> One of the major wrinkles is ... well, m_getfld() is a complicated hot
> mess.  I know some of the people here have been inside of it; if they
> wanted to impart some public knowledge here about it, I for one sure
> would appreciate it.

my thought is, fire photon torpedoes. m_getfld was the wrong approach
when it was new but it worked well enough (especially on slower older
machines). we should not compromise on readability in order to keep the
couple hundred places that call m_getfld from having to change.

...
> A few other things:
> 
> - I know work on nmh tends to be bursty ... and in my case, that's
> definitely true.  I think I am going to have to work on other things
> soon, and I don't know if I'll get a chance to get to the MIME work.
> 
> - Given the above ... do people think there is value in rolling
> another release soon-ish?  We've got a number of a bug fixes, a new
> build system, significant improvements to the format strings that let
> people (in some cases) select headers based on message contents, and
> if I get the repl work done then that means one of my
> long-outstanding beefs about replies will be solved (not the biggest
> one, sadly, but we can't have everything).

yes, i think so, definitely.

> - I know Paul Vixie was asking about putting most of nmh in a shared
> library, and I think I've done 70% of that work with the Automake
> migration. If someone wanted to take that over the finish line, I
> think that would be great.  A quick glance at the Libtool manual
> suggests that it shouldn't be hard.

i'd like to emphasize that whether the library is shared or not is the
least of our worries. we need a sensible, abstract, modular, data
hiding API. even if we go on statically linking everything.

and there's no way to get that in the 1.x version stream.

the work in 1.4, and since 1.4, deserves release.

-- 
Paul Vixie