[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: Daiki Ueno
Subject: Re: Moving files from lisp/gnus/ to lisp/net/?
Date: Sun, 11 Nov 2007 09:04:19 +0900
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>> password.el itself is in lisp/gnus/.  But we need a new function which
>>> does password caching, whose arglist is similar to read-passwd's, and
>>> whose name is longer than `read-passwd'.
>>> What about this patch?
>> Sorry for consecutive post but this might be better regarding argument
>> order.
> I think the docstring should make it very clear that the caller should
> be careful to remove the password from the cache in case it turns out
> not to be right.
> Or even make it more clear that this is not the thing to use because the
> password should only be added to the cache after checking its validity.

Agreed.  I perhaps misunderstood Simon's arguments in the first post

In that case, I think the most part of the existing API of password.el
is sufficient enough:

- password-read-from-cache KEY
  Obtain passphrase for KEY from time-limited passphrase cache.

- password-cache-add KEY PASSWORD
  Add password to cache.

- password-cache-remove KEY
  Remove password indexed by KEY from password cache.

However, `password-read-and-add' and `password-read' look awkward as
interface function.  Because `password-read-and-add' is not capable of
checking the validity of the password as you say, and `password-read'
has somewhat misleading name to use.  In addition, they does not provide
a way to pass CONFIRM and DEFAULT args to `read-passwd' while they call
`read-passwd' internally.

- password-read-and-add PROMPT &optional KEY
  Read password, for use with KEY, from user, or from cache if wanted.
  Then store the password in the cache.  Uses `password-read' and

- password-read PROMPT &optional KEY
  Read password, for use with KEY, from user, or from cache if wanted.

How about just making these two functions obsolete?

Daiki Ueno

reply via email to

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