From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Moving files from lisp/gnus/ to lisp/net/? Date: Fri, 29 Oct 2004 23:25:47 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <2366.81.51.30.174.1098020712.squirrel@yxa.extundo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1099085210 2729 80.91.229.6 (29 Oct 2004 21:26:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Oct 2004 21:26:50 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 29 23:26:39 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CNeGd-0002Bm-00 for ; Fri, 29 Oct 2004 23:26:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNeOU-0008J8-UW for ged-emacs-devel@m.gmane.org; Fri, 29 Oct 2004 17:34:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNeOG-0008FJ-Qw for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:34:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNeOG-0008EA-5t for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:34:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNeOG-0008Dy-3J for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:34:32 -0400 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNeFt-0001yd-Ha for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:25:53 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CNeFs-0006DS-00 for ; Fri, 29 Oct 2004 23:25:52 +0200 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 23:25:52 +0200 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Oct 2004 23:25:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 60 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:T7DaAscwp7RYixAPsAn+/L7VZX4= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29153 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29153 Richard Stallman writes: > Other applications typically ask the user whether they want to > remember the password in memory. If read-passwd is changed to cache > passwords (however, to use the cache, callers of read-passwd must be > updated, to provide the "key" into the hash table), it could ask the > user this. Opinions on this welcome. > > Having it always ask would be too annoying, I think. So that would > need to be a new argument, which means the feature is no benefit > unless we change the callers. > > That is the wrong thing to do at present. So I think we should put > read-passwd back where it was and remove the new file for now. I agree, password.el was only something that might go in when we aren't in a feature freeze. I have backed out the change. Since password.el will be used by Gnus CVS, our discussion haven't been in vain, though, since I will incorporate some of the ideas discussed here. > Looking ahead to the future, > > > Why have both password-read and password-read-and-add? > > Why not always add? Is the idea that for some purposes > > it is ok to cache, but for others it is too risky? > > No, the reason was this: if the user entered an incorrect password, it > should not be cached. If an incorrect password is cached, the code > might infloop trying the incorrect password automatically over and > over again. It was considered safer to first read the password, then > try to use it, and if successful then it is cached. > > In that case, password-read-and-add makes no sense, right? > Why add a shortcut that in best practice should not be used? It was added later on, not by me. I suppose he who added it might argue that it is useful, though. I tend to think that there should only be one worked out interface. (I'm not saying the current API, without p-r-a-a is the best interface, only that it would be better with only one interface.) > I'm not sure my argument is good, it may be simpler to always cache, > and have the calling code invoke password-cache-remove whenever there > is a password failure. > > That is a reasonable alternative, I guess, but then password-read > should add the password and we should not have password-read-and-add > as a separate entry point. I think so too. > But it doesn't make sense to discuss this without dealing with the > question of whether caching of correct passwords is desirable. Perhaps the experience with how password.el is used in Gnus CVS will help in sorting things out. Thanks.