[Top][All Lists]

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

Re: [Nmh-workers] More configuration stuff (acconfig.h)

From: Paul Vixie
Subject: Re: [Nmh-workers] More configuration stuff (acconfig.h)
Date: Thu, 05 Jan 2012 20:02:26 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 1/5/2012 7:14 PM, Ken Hornstein wrote:
> Alright, in preparation for finally cleaning up our suboptimal autoconf
> mess, I am tackling acconfig.h (a template which users can edit to
> change defaults).  My feeling is all of that should either be controlled
> by autoconf or we take a decision on whether or not to keep or remove
> that code.  Here is the list:
> LOCKDIR               - A directory to place lock files in if you're using
>                 DOT_LOCKING.  I've never been happy with nmh's use of
>                 dot locking, but do people actually use this?  It's
>                 easy enough to add the support for this to autoconf.

i think if it's easy to move to autoconf then we should preserve this,
noting that Maildir does locking better and we will eventually move this
logic into some kind of abstraction layer for mail store access.

> DBMPWD                - The comment says "Define this if your passwords are
>                 stored in some type of distributed name service, such as
>                 NIS, or NIS+."  This only affects aliasbr.c ... and I
>                 guess what it does is controls whether or not names
>                 are cached from calls to getpwnam().  This has been
>                 turned on forever, I propose just removing the #ifdefs
>                 and making that code the default.

yes. by which i think you can remove the cache logic?

> DUMB          - Strangely, turning ON DUMB means you get an RFC 822
>                 parser.  If DUMB is NOT defined, you get MMDF and UUCP
>                 parsing as well.  I'm going to go out on a limb here and say
>                 we can safely remove MMDF & UUCP address parsing :-)
>                 Oh, on that note there's some code #ifdef'd as BANG
>                 which uses UUCP mailing syntax.  I'm just going to go
>                 ahead and remove that because I am 100% sure no one
>                 needs it.


>               - Meh, at this point I'd say garbage collect this code,
>                 but I have no strong feelings.  Either we should keep it
>                 and remove the #ifdefs, or get rid of it entirely.
>                 Thoughts?

+1, nuke it. this code will be around in the year 2100; let's let those
people think we were "daring".

> SLOCAL_MBOX   - If defined, use mbox format with slocal when saving to
>                 your mail spool, otherwise, use MMDF.  I say keep it
>                 and ditch MMDF support.


> MHRC          - Handle the ~ for filenames; this is a keeper, right?

yes. though i really wish posix fopen() had just institutionalized ~.

> POPSERVICE    - Easy enough to autoconf it, but it's command-line selectable
>                 anyway.  Maybe simply hardcode the default?


> DEFAULT_FOLDER_MODE   - Leave these two as hardcoded defaults?
> LINK          - The same?


> ATTVIBUG      - Is this an issue anymore?

if we believe we're requiring POSIX from x>1.4 onward, then it by
definition cannot be an issue any more.

reply via email to

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