From: Paul Franklin <paul@cs.washington.edu>
Subject: Re: future wishes - ACAP and LDAP support
Date: 05 Oct 1997 10:02:27 -0700 [thread overview]
Message-ID: <r9q90w89m8s.fsf@fester.cs.washington.edu> (raw)
In-Reply-To: Hrvoje Niksic's message of 04 Oct 1997 21:17:11 +0200
Lars asked for comments, so I figure I'll share mine.
Here's a more concrete proposal which builds on Hrvoje's ideas...
(if I only had time to code)
nnmail-spool-methods becomes a server variable, containing a list of
methods. We start with the following methods, so that implementing
spool methods isn't an issue yet:
* default (old behavior--chooses between simple & movemail)
* simple (emacs does everything itself)
* movemail (calls external movemail program)
These all take the same string as nnmail-spool-file does,
which defaults to the same things as nnmail-spool-file.
Also, movemail can take a second string--a path to movemail.
* vmpop (calls vm's pop code, which many folks say works well)
This one takes the same string that vmpop does.
[Sidenote--does vmpop stash its password someplace
secure after prompting for it?]
So I might have this in my nnml server definition:
(nnmail-spool-methods
(simple "~/Gnus/outgoing")
(vmpop "pop.cs.washingon.edu:110:pass:paul:*"))
Then, of course, there's backwards compatibility. I propose not
making things strictly backwards compatible, instead making things
work how novice users probably expect, and forcing expert users to
possibly do some work. A server would only use nnmail-spool-file if
all of these apply for that server:
* The server is the first mail server in the list of
(cons native-server secondary-servers)
* nnmail-get-new-mail is t
* nnmail-spool-file is well-defined
* nnmail-spool-methods is not defined
Then nnmail-get-new-mail would still default to t; people actually
using nnmail-spool-methods would normally set it to nil.
These restrictions would help people not shoot themselves in the foot
when they play around and add a second mail server. (Hmm.
Non-native/secondary (editable) servers could notice if
nnmail-spool-methods is not defined, and ask whether it should be set
to nil or (default), to help out folks who create their first mail
server from the server buffer and want it to get new mail. Did that
make sense?)
--Paul
next prev parent reply other threads:[~1997-10-05 17:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-09-30 22:40 Richard Coleman
1997-10-01 1:38 ` Andrew J Cosgriff
1997-10-01 2:36 ` Jason R Mastaler
1997-10-01 6:57 ` Rolf Marvin B|e Lindgren
1997-10-01 14:31 ` William M. Perry
1997-10-03 22:10 ` Lars Magne Ingebrigtsen
1997-10-03 23:11 ` David Kågedal
1997-10-12 13:11 ` Lars Magne Ingebrigtsen
1997-10-04 19:17 ` Hrvoje Niksic
1997-10-05 17:02 ` Paul Franklin [this message]
1997-10-12 13:48 ` Lars Magne Ingebrigtsen
1997-10-05 10:00 ` Kim-Minh Kaplan
1997-10-05 20:29 ` Kai Grossjohann
1997-10-12 13:50 ` Lars Magne Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=r9q90w89m8s.fsf@fester.cs.washington.edu \
--to=paul@cs.washington.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).