From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Asynchronous DNS Date: Mon, 08 Feb 2016 20:20:31 +0200 Message-ID: <83wpqfoyhc.fsf@gnu.org> References: <87si1gx6wz.fsf@gnus.org> <86y4b5zvzt.fsf@gmail.com> <8760y9kwrk.fsf@gnus.org> <8760y7nag7.fsf@gnus.org> <83oabzzsjq.fsf@gnu.org> <87fuxazkfe.fsf@gnus.org> <83io25yeqk.fsf@gnu.org> <87h9hpnreg.fsf@gnus.org> <83y4b0wi7m.fsf@gnu.org> <87si17evk6.fsf@gnus.org> <83twlnvcz2.fsf@gnu.org> <87vb63obm3.fsf@gnus.org> <87r3gqmg6g.fsf@gnus.org> <83egcqtfnm.fsf@gnu.org> <87bn7tjo9x.fsf@gnus.org> <83egcosdvr.fsf@gnu.org> <87wpqg3qjk.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454955667 16714 80.91.229.3 (8 Feb 2016 18:21:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2016 18:21:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 08 19:21:01 2016 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 1aSqQl-0003DT-EJ for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 19:20:59 +0100 Original-Received: from localhost ([::1]:47550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSqQk-0001jk-KI for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2016 13:20:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSqQd-0001ip-S2 for emacs-devel@gnu.org; Mon, 08 Feb 2016 13:20:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSqQZ-0002Tb-RS for emacs-devel@gnu.org; Mon, 08 Feb 2016 13:20:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSqQZ-0002TO-O0; Mon, 08 Feb 2016 13:20:47 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1571 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aSqQZ-0006SA-0C; Mon, 08 Feb 2016 13:20:47 -0500 In-reply-to: <87wpqg3qjk.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 08 Feb 2016 13:05:19 +1100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:199543 Archived-At: > From: Lars Ingebrigtsen > Cc: emacs-devel@gnu.org > Date: Mon, 08 Feb 2016 13:05:19 +1100 > > >> Again, it is not demonstrated by ERC. ERC works fine with the new > >> refactoring. > > > > I would like us to avoid the need for refactoring. With my > > suggestion, the refactoring would only be needed if the application > > wants to take full advantage of the async DNS resolution, but it will > > still work correctly (albeit with some delays) if no refactoring was > > done. > > By "refactoring" I just mean "the rewrite of make_network_process that > turned it from one 700-line soup of interconnected code into two 350 > line functions of less interconnected code". I'm talking about refactoring in the applications that _use_ make-network-process. It's their refactoring that I would like us to avoid, if possible. IOW, let the maintainers of those applications decide how deeply they want to refactor, and at what time schedule, instead of requiring them to make a binary all-or-nothing choice, which might be a price that is too heavy for them to pay. ("Them" here might mean us as well: we do have in Emacs quite a few features that build elaborate applications on top of network APIs.)