Gnus development mailing list
 help / color / mirror / Atom feed
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


  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).