Re: auth-source tokens

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 14 Nov 2010 18:24:50 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Fri, 29 Oct 2010 10:04:59 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 
>> 
>>>> A string value is matched as a regex for the
>>>> file (netrc) backend and literally by the Secrets API.  A symbol
>>>> is matched as its string value.  All the SPEC values can be
>>>> single values or lists.
>> 
MA> Hmm, maybe we shall extend secrets.el to support also regexp search?
>> 
>> It would be nice to make the interface consistent.

MA> OK. I'll check next days whether secrets.el can be extended this
MA> way. The Secrets API doesn't support it, it checks the attribute values
MA> "... via case-sensitive string equality". That means all token must be
MA> retrieved using only attribute matches which are *not* a regex. From the
MA> resulting tokens those must be removed, whose attributes with regex do
MA> not match.

Hrrrrm.  I guess we can pass "" and then examine the results directly.
But it sucks.  OTOH I don't see a need for substring or regex searching
for secrets anyhow, now that I think about it.  Is it really necessary?

MA> I still have a comment:
...
MA> How do you handle attributes which have a regex as value in SPEC? They
MA> shouldn't be created with that value.

Good catch.  I was thinking of them in Perl terms, where a regex is a
distinct kind of object and forgot ELisp doesn't have that luxury.  So
either we go with the plan above to allow only exact matching or we
create a special kind of object that can be passed to the search
function to indicate a regex search (and said object can carry the
creation value).

My vote is to do exact matching only.  It will produce simpler code and
will be easier to understand in the manual.  If it's going to be used
all over Emacs, it should be so.

Ted