[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Third-Party url.el replacement or wrapper packages
From: |
Björn Bidar |
Subject: |
Third-Party url.el replacement or wrapper packages |
Date: |
Thu, 08 May 2025 11:42:11 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hello,
Recently I started looking again into ement.el which uses plz.el a curl
instead. However plz.el is just a reference there are others such as
request.el.
A few years ago there was a similar conversation:
https://mail.gnu.org/archive/html/emacs-devel/2020-12/msg01217.html
The points that where left in the conversation:
- Add request.el to GNU ELPA
This one went no where and now there's plz.el in ELPA which
does something similar except that it requires the curl command.
- Add Curl support to url.el
This could help to make url.el more popular, however
Curl isn't the only reason alternative http libraries exist.
RMS suggested to use the curl command here instead of the libcurl
library. This one made me wonder why would that be the better option?
For example for SSL/TLS the support for gnutls-cli was dropped in
favor of using libgnutls instead. Why would using the command line
curl in this instance ok?
My question or point of this message is there anything that can be done
to make url.el more attractive?
One question with this I had is why reinvent the wheel in this
when we could use a much more popular HTTP library such as Curl
where there is more more manpower to keep it secure, up to modern
standards and functional?
Good Day,
Björn
- Third-Party url.el replacement or wrapper packages,
Björn Bidar <=