Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: ding@gnus.org
Subject: Re: auth-source.el rewrite
Date: Sun, 30 Jan 2011 20:49:00 -0600	[thread overview]
Message-ID: <877hdldbz7.fsf@lifelogs.com> (raw)
In-Reply-To: <87y663hk9n.fsf@gmx.de> (Michael Albinus's message of "Sat, 29 Jan 2011 15:11:48 +0100")

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Sat, 29 Jan 2011 15:11:48 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

>> The problem is that you don't know which SPEC keywords should be used
>> for creation and some backends may not support some keywords.  I'd
>> rather make it explicit, where there's a base list (for netrc: host user
>> protocol secret) and the user can augment it.  That's also the only way
>> to pass the default prompt, meaning a value we'd like to suggest to the
>> user but which they can override.  For example this:
>> 
>> (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1
>> :create t :create-extra-keys '((A "default A") (B)))

MA> This results in 

MA> Debugger entered--Lisp error: (void-variable A)
MA>   symbol-value(A)
MA>   (and (symbol-value r) (listp (symbol-value r)))

I think I'll just keep all the values in an alist instead of setting
symbol values.  It will simplify the code, too.

MA> For me, the argument list looks a little bit ugly. Couldn't we merge at
MA> least :create and :create-extra-keys, and use keys for the extra keys?
MA> Something like

MA> (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1
MA> :create '(:A "default A" :B))

MA> The value for :create could also be t, when there are no extra
MA> keys. :replace-existing could be a special key in the list, which is not
MA> added to the new entry.

You're right that it's ugly.  How about a simple alist
`auth-source-creation-defaults' that can be let-bound around the
function call?  Then the default prompts would not be necessary and we
can just have

(let ((auth-source-creation-defaults '((user "defaultUser") (A "default A"))))
  (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1 
                      :create '(A B)))

which would say "If you have to prompt for the user or A, use those
default prompts.  There is no default for B but it should be in the new
entry."

That removes a lot of special cases in the arguments so I like it.  Also
it gives us a way to override the default prompt for the required keys
(host user protocol) for the netrc backend, which was not allowed before.

I think I should eliminate the :replace-existing mode.  It's confusing
to merge search and conditional creation like that.  All the :max 1
conditions were just a pain for both the library and the API user.  I'd
rather provide a deletion facility so we can say

(when (setq entry (nth 0 (auth-source-search spec)))
...
  (when (auth-source-delete entry)
     ... modify entry as needed, adding :create t or whatever else
     (setq success (apply 'auth-source-search entry))))

I put a full example for the :create option in the docs, see the
attached source below.  It's not implemented, just the docs are done.
What do you think?  I like it better, it's clear what it does and how it
does it.  Also I made creation include only the keys in :create, not any
search key.

MA> Any string works as [password-cache] key. In Tramp, I do it similar
MA> (serializing method, user, host, protocol). No big deal.

Oh, OK.  Looking at the source, I thought it was a problem.  Thanks for
explaining.

Ted


[-- Attachment #2: auth-source.el --]
[-- Type: application/emacs-lisp, Size: 43176 bytes --]

  reply	other threads:[~2011-01-31  2:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25  2:59 nnimap-username Daiki Ueno
2010-10-25  6:33 ` nnimap-username Reiner Steib
2010-10-25  7:13   ` nnimap-username Daiki Ueno
2010-10-25 18:09     ` auth-source tokens (was: nnimap-username) Ted Zlatanov
2010-10-26 16:56       ` auth-source tokens Ted Zlatanov
2010-10-29  8:04         ` Michael Albinus
2010-10-29 22:15         ` Lars Magne Ingebrigtsen
2010-11-11 16:22           ` Ted Zlatanov
2010-11-14 17:24             ` Michael Albinus
2010-11-15  0:59               ` Ted Zlatanov
2010-11-15  4:47                 ` Michael Albinus
2010-11-15 15:14                   ` Ted Zlatanov
2010-11-15 16:03                     ` Michael Albinus
2011-01-24 17:27                       ` auth-source.el rewrite (was: auth-source tokens) Ted Zlatanov
2011-01-24 23:36                         ` auth-source.el rewrite Lars Ingebrigtsen
2011-01-25 16:59                           ` Ted Zlatanov
2011-01-25 21:09                             ` Michael Albinus
2011-01-25 21:42                               ` Ted Zlatanov
2011-01-26  8:32                                 ` Michael Albinus
2011-01-26 17:03                                   ` Ted Zlatanov
2011-01-26 19:35                                     ` Michael Albinus
2011-01-26 20:35                                       ` Ted Zlatanov
2011-01-26 22:15                                         ` Ted Zlatanov
2011-01-27 16:49                                           ` Michael Albinus
2011-01-27 20:20                                             ` Ted Zlatanov
2011-01-29 14:11                                               ` Michael Albinus
2011-01-31  2:49                                                 ` Ted Zlatanov [this message]
2011-01-31 14:30                                                   ` Michael Albinus
2011-01-31 17:09                                                     ` Ted Zlatanov
2011-01-27 12:35                                         ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877hdldbz7.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).