Re: secure plist store

[Daiki Ueno]

Ted Zlatanov <address@hidden> writes:

> 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).

I'm now confused about that, while those members are set in
auth-source-backend-parse-parameters, they are not referred from any
code in auth-source.el.  Am I missing something (I tried M-x occur oref
and slot-value)?

> 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.

I meant EIEIO with "CLOS".  From the EIEIO doc:

  EIEIO ("Enhanced Implementation of Emacs Interpreted Objects") is a
  CLOS (Common Lisp Object System) compatibility layer for Emacs Lisp.

I was really confused about auth-source.el usage of EIEIO, where
defclass is only used as defstruct.  It looks simply overkill such a
purpose and misleading.

Regards,
-- 
Daiki Ueno