From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Sv: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?] Date: Tue, 30 Mar 2021 15:50:53 +0300 Message-ID: <83y2e4kdoy.fsf@gnu.org> References: <87r1jxd3d8.fsf@gnu.org> <8e549f23-db75-2ef1-4399-0fb52e5efa6f@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2469"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arthur.miller@live.com, emacs-devel@gnu.org, db48x@db48x.net, darnir@gnu.org, adam@alphapapa.net, raman@google.com, jemarch@gnu.org To: Daniel =?utf-8?Q?Mart=C3=ADn?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 30 15:00:01 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lRDyS-0000WM-FH for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Mar 2021 15:00:00 +0200 Original-Received: from localhost ([::1]:59888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRDyR-0002yR-H2 for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Mar 2021 08:59:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRDpW-0001kR-Lr for emacs-devel@gnu.org; Tue, 30 Mar 2021 08:50:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36500) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRDpT-0000lK-W1; Tue, 30 Mar 2021 08:50:44 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2793 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRDpS-0006YR-O0; Tue, 30 Mar 2021 08:50:43 -0400 In-Reply-To: (message from Daniel =?utf-8?Q?Mart?= =?utf-8?Q?=C3=ADn?= on Tue, 30 Mar 2021 14:03:58 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267166 Archived-At: > From: Daniel Martín > Cc: Darshit Shah , "T.V Raman" , Daniel > Brooks , Adam Porter , > "emacs-devel@gnu.org" , "Jose E. Marchesi" > > Date: Tue, 30 Mar 2021 14:03:58 +0200 > > Arthur Miller writes: > > > > > Thanks for the answer. No idea if there is a consideration to include > > new library or not, I got impression from some other discussions on this > > list, it is rather not. > > I also think that having a better networking library could be a great > addition to Emacs. But before we decide on introducing a curl or wget > dependency, I think we should do some analysis on url.el, to be sure > about the trade-offs of the proposed new approach to do networking, > compared to what we already have. It's actually more than that: to start discussing this seriously, Someone™ should study the issue and present a design proposal: which functions currently implemented in process.c and/or in Lisp are proposed to be replaced or redesigned/rewritten. It is not enough to say let's use this networking library, because network communications in Emacs are tightly coupled with process objects and with primitives that perform background I/O, and also with the filter and sentinel functions. The best (and perhaps also the only practical) way of using such a library is as a drop-in replacement for some functions, but then someone should make concrete proposal regarding what is to be replaced and how. > - url.el has strange/buggy behavior in some scenarios. For example, > callbacks are run multiple times, or not at all. This blog post[1] > presents some of those problems, but it doesn't offer much details > about why they happen. The blog post is from 2016, so things might > have changed since then. > > - url.el is slow compared to using curl as an inferior process. Again, > the blog post cites some possible culprits, which I don't know if they > still apply to Emacs 28, so I think we should profile url.el to > identify its bottlenecks more precisely. Much has happened since 2016; in particular the network code is much more asynchronous these days on modern platforms. Not sure how that blog measures against what we have now. One issue that one must keep in mind when talking about external libraries is support for non-ASCII characters: such libraries usually support only the current locale, so if that is not UTF-8, it may mean restrictions and subtle issues. By contrast, Emacs's own code is independent of the locale, and completely under control of Lisp programs and users.