Re: [Nmh-workers] cleaning out the cobwebs

[Lyndon Nerenberg]

> 5906    10/29 XXXXXXXXX XXXXXXX  Re: Coming down your way soon<<Thanks. I am 
> doin
> 5907+   10/29 XXXXXXX XXXXXXXXX  Election editorial 
> cartoons<<--Apple-Mail-19-856
>  .1           text/html          I decided to stick to just one topic, since 
> the
>  .1.2         image/gif          JGPfwdtoon.gif
[...]
>       show 5907.1.2
> or maybe if 5907 is the current message just the ability to do something like
>       show .1.2

I like this, provided it requires a switch to enable it so that we don't
break existing scripts that parse the current default scan format.

>       next -part
>       prev -part

What if the "next part" is a message/rfc822? Do you descend into it
recursively?  Interesting idea, but the semantics will need some careful
thought methinks.

> Again, the stumbling block here is m_getfld.c and my not wanting Van 
> Jacobson, his
> children, and my children cursing me as per the comments.

The day of the VAX is long gone, and with it, the need for this sort of
bowing down to the necromancer.  When a piece of code gets this
disgusting the best path forward is to throw it out and rewrite it.

> In my mind, the best way to start a clean-up project is for people to go into 
> the
> existing code and add good comments.  As with m_getfld.c, the big stumbling 
> block
> is not understanding what the stuff that's already there does.  Once it's 
> understood
> it's probably pretty easy to change.

Here we disagree.  It's a waste of time commenting code that's just
going to be ripped out.  From what I see there are two immediate tasks
that can be taken on without too much pain:

* replace HAVE_* defines with POSIX calls, eliminating autoconf.
* remove old compatibility cruft (KPOP, ZMAILER SMTP workarounds, site
specific hacks)

These alone will substantially improve the readability of the code in
many places.  Once that's done it will be easier to move forward with
general feature cleanup.

> BTW, it seems to me that part of what's going on in m_getfld.c is poking 
> around in
> stdio buffers to avoid fetching the data twice.  Most message are pretty 
> small so
> I've wondered whether it would be better to just memory map the files.  Or, 
> maybe
> systems are fast enough today that we can just bail on the tricky stuff and 
> use
> stdio.

Stay away from mmap.  It's not portable, and it's doubtful it would give
any visible performance gain in a non-contrived scenario. stdio is more
than fast enough for the job, and portable.

--lyndon