Re: auth-source multiple accounts

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 27 Jul 2010 18:19:13 +0100 Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote: 

USR> Ted Zlatanov wrote:
>> I mean "machine" will still be the server name but VM will also pass an
>> optional (account "xyz") query parameter to
>> auth-source-user-or-password, which will find "account xyz" in the netrc
>> file.
>> 
>> I'll add another optional parameter QUERIES to
>> auth-source-user-or-password.  It will be an alist.  When a query is not
>> specified you'd still get the first match (thus it's backwards
>> compatible).  Does all that sound reasonable?

USR> Adding a QUERIES parameter is good but I would urge you to allow
USR> (login "xyz") as a possible query.

USR> For looking up email passwords, the "account" attribute seems like an
USR> overkill. What would users put as their "account", if not their login
USR> id?  Since they are already using the "login" parameter to write their
USR> login id, it seems like unnecessary duplication.

I want to make it more generic with QUERIES since not every auth-source
API user will want the login ID to be a query key.  VM and Gnus have
this kind of data hierarchy but url*.el doesn't, for example.  I think
that's a good compromise and doesn't extend the API too much.

From VM you would pass me (k v) as the query, e.g. (login "xyz").  In
the netrc/authinfo file, then, I would match only lines with

.... login xyz ....

in them.  So the query key and value are a contract between the
application and the user.  auth-source is just a conduit.  If VM
standardizes on (login "xyz") then we'll add a VM-specific section to
the auth.texi manual giving an example.  For Gnus we'll probably use
(server "xyz") because the Gnus configuration hierarchy is structured
that way.

Ted