emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: secure plist store


From: Ted Zlatanov
Subject: Re: secure plist store
Date: Thu, 30 Jun 2011 09:54:54 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Thu, 30 Jun 2011 22:42:31 +0900 Daiki Ueno <address@hidden> wrote: 

DU> Ted Zlatanov <address@hidden> writes:
>> Also you added a generic "arg" parameter to the backend.  The other
>> parameters are named: source, host, port, user, type.  Can the name be
>> more specific, so we don't have to guess what it means?  In your case,
>> it's set to
>> 
>> (plstore-open (plist-get entry :source))
>> 
>> which is, I think, the plstore instance, a defstruct-like vector.  So
>> maybe the parameter should be called "data" or "instance" or
>> "internal-data"?  WDYT?

DU> I don't care about that - maybe host/port/user (currently unused?) can
DU> also be "internal-data".

They are used.  See the backend filtering in `auth-source-search'
coupled with `auth-source-backend-parse-parameters'.  When you specify a
simple string as an auth-source, the host, port, and user are nil (so
that backend instance applies to every host, port, and user).

Since you don't care, I've renamed "arg" to "data".  There is no
functional difference.

DU> Frankly I don't see any reason to use defclass here - why not using
DU> CLOS inheritance if you want to define members specific to some
DU> class derived from auth-source-backend (I mean host/port/user are
DU> only valuable for Secrets API backend)?

For this case, EIEIO worked better for me.  I've found some issues with
it, but overall it's a nice system that covers a lot of ground that
CLOS does not.

Ted




reply via email to

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