From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76452 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: tzz-auth-source-rewrite branch Date: Mon, 07 Feb 2011 12:14:53 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87vd0viuea.fsf@lifelogs.com> References: <87ei7nivte.fsf@lifelogs.com> <87zkq9tdi7.fsf_-_@lifelogs.com> <87bp2p3t56.fsf@gmx.de> <87lj1tt0u4.fsf@lifelogs.com> <87r5bkc33j.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297102525 12804 80.91.229.12 (7 Feb 2011 18:15:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 18:15:25 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M24800@lists.math.uh.edu Mon Feb 07 19:15:21 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PmVcO-0007gX-C5 for ding-account@gmane.org; Mon, 07 Feb 2011 19:15:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PmVcL-0006Cr-Ur; Mon, 07 Feb 2011 12:15:17 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PmVcK-0006Bs-KC for ding@lists.math.uh.edu; Mon, 07 Feb 2011 12:15:16 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PmVcJ-000240-5S for ding@lists.math.uh.edu; Mon, 07 Feb 2011 12:15:16 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PmVcI-00046X-Co for ding@gnus.org; Mon, 07 Feb 2011 19:15:14 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PmVcI-0007cT-16 for ding@gnus.org; Mon, 07 Feb 2011 19:15:14 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Feb 2011 19:15:14 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Feb 2011 19:15:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 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" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:jlxpsL9KimFeuMRIzUljYwLdsKk= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76452 Archived-At: On Sun, 06 Feb 2011 21:36:32 +0100 Michael Albinus wrote: MA> Mid-term, we could improve the returned function to check/add caches MA> as well. I thought the cache would only be at the top level of `auth-source-search', keyed on (format "%S" spec) and nothing else. Any creation or deletion on a backend would clear that backend's cache (we'd know which result lists involve a backend because :type and :source in the cached result list would match). Do you mean something else here? MA> Ted Zlatanov writes: >> I think we should support the Google Chrome schema, at least: >> >> username_value => user >> origin_url => protocol (using the protocol piece of the URL) and host >> (using the host piece) >> >> Those values won't work for creation (meaning we won't be able to create >> valid Chrome entries without user assistance), but at least there's a >> good chance that the user can reuse their Chrome passwords. Is that >> reasonable? Do you know of any other software that has its own schema >> like Chrome does? MA> Once I've heard that Firefox will use it as well. I haven't seen it. MA> I know that it is used by Nautilus, UbuntuOne, Desktop Couch, Deja Dup MA> backup, some IRC clients, ... I'm concerned that this will break the idempotent searches (compare to the netrc backend, where every entry returned will match itself as a search spec). To do it like netrc does, we would require a full retrieve of all the objects, which is prohibitively slow. So I won't do it for now, though I'd love to hear suggestions on how to handle this problem better. Ted