[Top][All Lists]

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

Re: Moving files from lisp/gnus/ to lisp/net/?

From: Simon Josefsson
Subject: Re: Moving files from lisp/gnus/ to lisp/net/?
Date: Fri, 29 Oct 2004 23:25:47 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Richard Stallman <address@hidden> 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.


reply via email to

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