Re: Sv: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: Darshit Shah <darnir@gnu.org>,  "T.V Raman" <raman@google.com>,  Daniel
>  Brooks <db48x@db48x.net>,  Adam Porter <adam@alphapapa.net>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>,  "Jose E. Marchesi"
>  <jemarch@gnu.org>
> Date: Tue, 30 Mar 2021 14:03:58 +0200
> 
> Arthur Miller <arthur.miller@live.com> 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.