[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] cleaning out the cobwebs

From: Mike O'Dell
Subject: Re: [Nmh-workers] cleaning out the cobwebs
Date: Thu, 04 Nov 2010 14:44:54 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

i strongly suggest that KPOP not be deprecated unless you can prove
there are no sites using Kerberized POP. (Hint - i know the answer)


On 11/3/10 2:05 PM, Lyndon Nerenberg wrote:
5906    10/29 XXXXXXXXX XXXXXXX  Re: Coming down your way soon<<Thanks. I am 
5907+   10/29 XXXXXXX XXXXXXXXX  Election editorial 
  .1           text/html          I decided to stick to just one topic, since 
  .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, 
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 
existing code and add good comments.  As with m_getfld.c, the big stumbling 
is not understanding what the stuff that's already there does.  Once it's 
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 
stdio buffers to avoid fetching the data twice.  Most message are pretty small 
I've wondered whether it would be better to just memory map the files.  Or, 
systems are fast enough today that we can just bail on the tricky stuff and use

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.


Nmh-workers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]