From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: secure plist store Date: Thu, 30 Jun 2011 17:34:29 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87sjqrq77u.fsf@lifelogs.com> References: <87wrh4b9h9.fsf@lifelogs.com> <87aae05l8p.fsf-ueno@unixuser.org> <87k4d4b66p.fsf@lifelogs.com> <87wrh0fh4g.fsf_-_@lifelogs.com> <87y60ncma8.fsf_-_@lifelogs.com> <87vcvrne02.fsf-ueno@unixuser.org> <87r56ep3sm.fsf@lifelogs.com> <874o39n171.fsf-ueno@unixuser.org> <87boxgr9f9.fsf@lifelogs.com> <87sjqry0it.fsf@lifelogs.com> <877h83xwoo.fsf-ueno@unixuser.org> <87oc1fv075.fsf@lifelogs.com> <87y60jvu8g.fsf-ueno@unixuser.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1309474182 11325 80.91.229.12 (30 Jun 2011 22:49:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 30 Jun 2011 22:49:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 00:49:38 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QcQ39-0003dg-Cj for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2011 00:49:31 +0200 Original-Received: from localhost ([::1]:36182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcQ38-0006Ys-Jx for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2011 18:49:30 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcPow-0003Jf-4w for emacs-devel@gnu.org; Thu, 30 Jun 2011 18:34:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcPou-0002BZ-0p for emacs-devel@gnu.org; Thu, 30 Jun 2011 18:34:49 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:46901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcPot-0002BT-Hk for emacs-devel@gnu.org; Thu, 30 Jun 2011 18:34:47 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QcPor-0007EK-Ii for emacs-devel@gnu.org; Fri, 01 Jul 2011 00:34:45 +0200 Original-Received: from 38.98.147.133 ([38.98.147.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Jul 2011 00:34:45 +0200 Original-Received: from tzz by 38.98.147.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Jul 2011 00:34:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 57 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.133 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:hkPAtAS/uBq7F7Kc0z08qoPVW0M= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141291 Archived-At: On Fri, 01 Jul 2011 07:18:23 +0900 Daiki Ueno wrote: DU> Ted Zlatanov 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