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

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I think the main issue is that url.el can often be rather slow,
>   > sometimes taking half a minute or more to complete a request that would
>   > take curl or other libraries a blink of an eye.
>
>   > If curl or whatever other method could be used to accelerate url.el, a
>   > lot of application in Emacs would become more feasible to use, without
>   > having to rewrite anything.
>
> I see.  No problem in making that faster.
>
>   > 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/?
> Would someone please tell me what names the entry points of request.el have?

request.el
Description: Text document

"Request.el has a single entry point.  It is `request'."


(cl-defun request (url &rest settings
                       &key
                       (params nil)
                       (data nil)
                       (headers nil)
                       (encoding 'utf-8)
                       (error nil)
                       (sync nil)
                       (response (make-request-response))
                       &allow-other-keys)
  "Send request to URL.

Request.el has a single entry point.  It is `request'.

==================== ========================================================
Keyword argument      Explanation
==================== ========================================================
TYPE          (string)   type of request to make: POST/GET/PUT/DELETE
PARAMS         (alist)   set \"?key=val\" part in URL
DATA    (string/alist)   data to be sent to the server
FILES          (alist)   files to be sent to the server (see below)
PARSER        (symbol)   a function that reads current buffer and return data
HEADERS        (alist)   additional headers to send with the request
ENCODING      (symbol)   encoding for request body (utf-8 by default)
SUCCESS     (function)   called on success
ERROR       (function)   called on error
COMPLETE    (function)   called on both success and error
TIMEOUT       (number)   timeout in second
STATUS-CODE    (alist)   map status code (int) to callback
SYNC            (bool)   If `t', wait until request is done.  Default is `nil'.
==================== ========================================================


* Callback functions

Callback functions STATUS, ERROR, COMPLETE and `cdr's in element of
the alist STATUS-CODE take same keyword arguments listed below.  For
forward compatibility, these functions must ignore unused keyword
arguments (i.e., it's better to use `&allow-other-keys' [#]_).::

    (CALLBACK                      ; SUCCESS/ERROR/COMPLETE/STATUS-CODE
     :data          data           ; whatever PARSER function returns, or nil
     :error-thrown  error-thrown   ; (ERROR-SYMBOL . DATA), or nil
     :symbol-status symbol-status  ; success/error/timeout/abort/parse-error
     :response      response       ; request-response object
     ...)

___________________

I mentioned it just because it is already a wrapper around both built
url and curl (the process not libcurl), so it already abstracts
everything needed to profile (I think).

I have used it privately in my code when I wanted to download some html
for text processing.