From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Wed, 19 Nov 2014 15:45:52 +0100 Message-ID: References: <87oas4h555.fsf@lifelogs.com> <87a93oh180.fsf@lifelogs.com> <83h9xw9zg3.fsf@gnu.org> <83d28k9yb9.fsf@gnu.org> <83ppcj9740.fsf@gnu.org> <871toze1tl.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416408400 24095 80.91.229.3 (19 Nov 2014 14:46:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 14:46:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 15:46:34 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xr6Wc-0001Zw-Ea for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 15:46:30 +0100 Original-Received: from localhost ([::1]:58823 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr6Wb-0005bb-51 for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 09:46:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr6WT-0005ad-NE for emacs-devel@gnu.org; Wed, 19 Nov 2014 09:46:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr6WK-0005s1-Pm for emacs-devel@gnu.org; Wed, 19 Nov 2014 09:46:21 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:43948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr6WK-0005re-Ir for emacs-devel@gnu.org; Wed, 19 Nov 2014 09:46:12 -0500 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Xr6W1-0005xr-7w for emacs-devel@gnu.org; Wed, 19 Nov 2014 15:45:53 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUjBhX59vD8/PwJAQmC UFHUvav36dJoJcG2AAACPUlEQVQ4jV2UsZLjIBBE5w588aK6VS7VSjFV2DllDY5tL5DLJfj/T7hG QrZvyczTTPc0BlJNj6WEMSSu1hhzKr/7jjYwYMdZD2x08w6+sCHdUirMfS15Ack35QngvIF1v/8w xjql2tLs1zv4NpqianP63tUrmCAxF3Dd1TcwQuKgsBLvItRXt8wuZ8+8T7IBmLLMl0U6B3V9fwEh OMa4BB/MTyBhNquc/gfDZKCds1KLkUI2L7tWYLycVHs1+hjnFwjWzQBznszxpvLjCT4tR4CchIn4 Ij6qRj9IGefE+WqOGSvddzAyxRCit+aYUgh+d9V3EFnYOmtOOQfPVaPr+9RyZkbqFzSyVIGCekyX NsJszHOy4r6DToXMMYhNW5gdlDjmq0Ycf4qnFRTpXPbbNab4BKt4nksHHOsxFTBV0JVcEdWCTglR YsxakVNsIBMtxYSW0e+g95cGZaH0AwhenCv44gKWorwOPv2uoLMP1bZFOEcAaU977MO8ztLCEjK0 RHdqxjyjBT5PnyEmZBz4SkJSM+Dg5tSGkJML6yImcaytumI/SZSG4AQjswrGtgBdSrwT9AJ5KcBo dp7kpMmcSK2dsofPpdweC2DIHDYwBEzHiJckEZWb6LZW6db6IHBO+gfwj8TeOFwfqmBrNboRbsyh ArNWrOA2hE/8pSaIbBU6AKh+bP5eKtAbOAA0RcWfcfk1xMvLAeDCZhfqflnfC2lLMwo7cH1Yiqhm iyX5CZpe2dXNtvQT9Nsz8gb+ATyq4jQ3pEOOAAAAAElFTkSuQmCC X-Now-Playing: Lori Carson's _Everything I Touch Runs Wild (1)_: "I Saw the Light" X-Hashcash: 1:23:141119:emacs-devel@gnu.org::MYSpIZxUG4fyNVya:000000000000000000000000000000000000000000DERT In-Reply-To: <871toze1tl.fsf@lifelogs.com> (Ted Zlatanov's message of "Wed, 19 Nov 2014 08:51:02 -0500") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.51 (gnu/linux) X-MailScanner-ID: 1Xr6W1-0005xr-7w MailScanner-NULL-Check: 1417013153.47235@AmnGm7h9IUDrYmuRne4ngg X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.224.195 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:177754 Archived-At: Ted Zlatanov writes: > Would it work to use the logic of "the buffer that initiated the > connection is in the foreground"? In that case, we could store the > buffer name as an optional record in the process info structure-- > `open-network-stream' could figure it out mostly automatically? Hm... so shr would tell `url-retrieve' that the buffer that the "user buffer" for the request is "*eww*", and then if that's the buffer that's active when url.el finally has decided which server to connect to, and the NSM decides to query the user -- then NSM would only query the user if the user's active buffer is the same buffer? I think that sounds practically doable, and I think it would solve the main problem, unless there are scenarios I'm not considering... hm... Yes! I though of one. >"? If you `M-x eww RET http://google.com RET', then we don't create the *eww* buffer until we have downloaded the HTML. (Which will actually be from https://www.google.com, since there's a redirect.) Meanwhile the user may well have left the buffer she typed `M-x eww' in, but that (probably) shouldn't stop NSM from querying about whether the user really wants to visit the version of https://www.google.com that seems to be signed by an invalid Chinese CA for some strange reason or other... I think? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no