From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/12527 Path: main.gmane.org!not-for-mail From: Paul Franklin Newsgroups: gmane.emacs.gnus.general Subject: Re: future wishes - ACAP and LDAP support Date: 05 Oct 1997 10:02:27 -0700 Sender: paul@cs.washington.edu Message-ID: References: <19970930184007.48935@redwood.math.gatech.edu> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035152047 4227 80.91.224.250 (20 Oct 2002 22:14:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:14:07 +0000 (UTC) Return-Path: Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by altair.xemacs.org (8.8.7/8.8.7) with ESMTP id LAA02641 for ; Sun, 5 Oct 1997 11:53:26 -0700 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with SMTP id NAA23751 for ; Sun, 5 Oct 1997 13:46:19 -0500 (CDT) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 5 Oct 1997 19:02:39 +0200 Original-Received: (qmail 4818 invoked by uid 504); 5 Oct 1997 17:02:32 -0000 Original-Received: (qmail 4815 invoked from network); 5 Oct 1997 17:02:32 -0000 Original-Received: from june.cs.washington.edu (128.95.1.4) by claymore.vcinet.com with SMTP; 5 Oct 1997 17:02:31 -0000 Original-Received: from fester.cs.washington.edu (fester.cs.washington.edu [128.95.4.119]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with ESMTP id KAA25475; Sun, 5 Oct 1997 10:02:29 -0700 Original-Received: (from paul@localhost) by fester.cs.washington.edu (8.6.12/8.6.9) id KAA00403; Sun, 5 Oct 1997 10:02:28 -0700 Original-To: ding@gnus.org In-Reply-To: Hrvoje Niksic's message of 04 Oct 1997 21:17:11 +0200 Original-Lines: 52 X-Mailer: Gnus v5.4.39/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:12527 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:12527 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