Re: secure plist store

[Ted Zlatanov]

On Fri, 01 Jul 2011 07:18:23 +0900 Daiki Ueno <address@hidden> wrote: 

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

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

`auth-source-search' will filter the backends with any keys that are
applicable before it actually searches each backend:

#+begin_src lisp
      (setq filtered-backends (copy-sequence backends))
      (dolist (backend backends)
        (dolist (key keys)
          ;; ignore invalid slots
          (condition-case signal
              (unless (eval `(auth-source-search-collection
                              (plist-get spec key)
                              (oref backend ,key)))
                (setq filtered-backends (delq backend filtered-backends))
                (return))
            (invalid-slot-name))))
#+end_src

So for instance a backend with host "x" will match a search spec of
:host '("x" "y") or :host "x".

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)?
...
DU> I was really confused about auth-source.el usage of EIEIO, where
DU> defclass is only used as defstruct.  It looks simply overkill such a
DU> purpose and misleading.

For now, yes, since we only had netrc and Secrets API backends, which
are too different, and the Secrets API didn't need most of the prompting
and modification functionality.  But notice how much code is shared
between plstore and netrc.  I'll take a look at using the EIEIO
inheritance to abstract the prompting and modification to a generic
file-based class from which the plstore and netrc classes will derive.
That was the original intent with the class hierarchy, at least.

I don't think, in any case, that it's overkill or misleading to use
EIEIO instead of defstruct.  In many ways it's a nicer API and even as a
simple defstruct stand-in it's better.  Perhaps it's not suitable for
large collections of objects, but `auth-sources' has at most a few
entries.

Ted