Re: [ELPA] New package: plz

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It's an HTTP library that uses Curl as a backend.
>
> I hope we can consolidate this with `request.el` and `url.el` sooner
> rather than later.  As others mentioned, adding a backend to plz which
> uses url.el (or at least doesn't require `curl` to be installed) would
> be great.

Some people don't like the interface but that was never the main problem
I had with url.el.  What caused me pain is its bugs, and I suspect for
many other package maintainers it is the same.

Right now though --and that is a first-- I am not aware of any bugs for
which I don't have backported a fix in ghub.el.  (If you must see code,
it is at the very end of ghub.el.  It ain't pretty.)

Of course I am not happy that I have to backport the fixes, especially
because that also affects other packages.  The hope is that those other
packages get bug fixes for free, but of course it is also possible that
my monkey patches contain bugs of their own.

It worries me that I might be breaking other peoples packages, but there
really is no alternative; these url.el bugs caused an endless stream of
bug reports in my packages, and once we figured out the causes, waiting
a few more years until the fixes are in Emacs just wasn't an option
anymore.

I am not saying that url.el is bad, but that maintaining such
functionality is a lot of work.  Doing so requires an expert whose main
or only focus it is to do just that.  So:

> The way HTTP is evolving, I suspect we're going to need to rely on
> C libraries (as opposed to url.el's "it's all ELisp" approach) in the
> not too distant future, tho.

Maybe that's not a bad thing and it is best if we do that sooner rather
than later?

Of course libcurl may have bugs too, but *many* people are using it,
making it highly unlikely that we are the ones who will have to figure
them out.

With url.el that is not the case.  If you use that, then you are going
to have to deal with bugs that have nothing to do with your own package,
if only your package is popular enough.

I think that hinders Emacs evolution as a network client.  Occasionally
I have had an idea that involved networking, but, given my experience
with forge/ghub, I never worked on any of them.  The risk of ending up
having to deal with mystery bugs as a result, currently is just to high.
I might not be the only one who feels that way.

     Jonas


TL;DR Maybe this was overly negative.  That wasn't my intention.  What I
really want to say is this: could someone™ with experience in this area
pretty please start working on bringing libcurl to Emacs?