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

[Ken Hornstein]

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

By my count it's actually only 77 calls to m_getfld().  So it's not
insurmountable by any means.

I was thinking that m_getfld() would actually have a couple arguments
added to it in terms of "here's the mime type of whatever data you
have".  Internally there would be a lot of rototilling.  But okay,
since you've thought about this more than I have ... what is _your_
vision of an API?  If you'd be willing to sketch something out that
sure would be great.

--Ken