nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] cleaning out the cobwebs

2010-11-03 13:06:15
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>