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

[Arthur Miller]

"Philip K." <philipk@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>   > Request.el is another story, and I can't comment on that. It's probably
>>   > just like with dash/s/f/... where non-elisp developers dislike the
>>   > built-in API, but I'm just guessing.
>>
>> From what people have said here, it sounds unproblematical.
>> But could you explain what you mean by comparing it with dash/s/f/?
>
> In my experience, people use dash/s/f when they are either unfamiliar
> with the built-in functions and macros, or when they find them too
> cumbersome to use (I'm sure there are exceptions, but again, this is my
> impression). So they want to write (s-join "+" '("abc" "def" "ghi"))
> instead of (mapconcat #'identity '("abc" "def" "ghi") "+"), and add an
> external dependency for this minor convenience.

Indeed. I think one problem is dicoverability. Built-in functions and
macros does not start always with what people would use as their first
guess. Thinngs like s-* orc -* are easier to look up (just one page on
github), easier to guess the name etc. Then we have things like
string-replace and replace-string: which one do you use if you are not
familiar with elisp? It asks for doc lookup, lookup breaks the workflow
and thought process, and so people probably find it easier to open
github page for s.el then bother to figure out how things are done
idiomatically in Elisp. 

> And again, in my experience this often motivates people to use request,
> though it might be a better example, because it actually does useful
> stuff, even though I don't always think it's idiomatic. The built-in
> url.el could use this as an inspiration, to add more macros/functions
> that simplify code.
>
> One notable difference is that it will use curl, the binary, instead of
> url.el if it's installed, which does notably accelerate network
> requests.

Yes, I think it was main goal of the the author - to use curl when
possible for the performance reasons; but I don't know for sure. Maybe
the author is reading this list and can step in and tell us.

I don't think it was same motivation as behind s/dash etc. It defines
asynchronous framework for use with networking. It is an "old" package,
at least since 2012, I don't remember if Emacs back then had threads or
not.