On Wed, 25 Jan 2012 22:40:58 -0500
Ken Hornstein <kenh(_at_)pobox(_dot_)com> 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers