emacs-devel
[Top][All Lists]
Advanced

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

Thanks.





reply via email to

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