From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?] Date: Sun, 20 Dec 2020 06:29:05 -0600 Message-ID: <87v9cwek4u.fsf_-_@alphapapa.net> References: <15c3cc00-f56e-6e52-2228-30817639315a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34691"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 20 13:31:57 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kqxsT-0008v8-DY for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Dec 2020 13:31:57 +0100 Original-Received: from localhost ([::1]:38412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqxsS-00037O-FG for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Dec 2020 07:31:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33148) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqxpr-0002Rr-VG for emacs-devel@gnu.org; Sun, 20 Dec 2020 07:29:15 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:48162) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqxpq-0002vg-6c for emacs-devel@gnu.org; Sun, 20 Dec 2020 07:29:15 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kqxpo-0006FJ-8y for emacs-devel@gnu.org; Sun, 20 Dec 2020 13:29:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261320 Archived-At: stardiviner writes: > More importantly: what do you want to do about `request`? > > About this, I really suggest ELPA can include it. Because I hate to > write more complex url requests with `url.el`. If someone want to > adopt kiwix.el request to use `url.el`. I also can't accept > it. Because I still need to write code on it. Also as you said, a > wrapper on `url.el` is good for developer. Emacs will need it. Really > helpful. Emacs definitely needs an alternative to url.el. It has some issues that are not easily solved nor worked around, such as potentially calling callbacks multiple times[0], requests not timing out, and some of its API being in the form of undocumented variables that must be let-bound around calls to its functions. I wrote a macro that wraps `url-retrieve' to help alleviate some of the issues.[1] Using it in matrix-client.el seems to make its use of url.el much more reliable (requests time out properly, etc). But I don't know if it would be suitable for general use, and it basically "papers over" some of these issues. request.el is a widely used library, and it works well for many things. However, it has its own not-easily-resolved issues that, IME, forced me to use url.el in the end--except for the things which url.el couldn't handle properly, such as some file uploads, which forced me to use request.el for those. Having to use two different HTTP libraries in matrix-client.el is...not ideal. Besides that, I doubt that request.el could be easily merged into ELPA since, apparently, not all of its contributors have done FSF copyright assignment. An issue that was raised about merging it into ELPA was closed without discussion or consideration.[2] And that leads to another concern, one I raised about its current governance, which has been ignored for a year now.[3] As Chris Wellons noted in some discussions I've had with him[4], it's relatively simple to write a Curl wrapper in Elisp that precludes having to use url.el. He did this for Elfeed, and it works very well. However, quite understandably, he isn't interested in factoring it out and maintaining it as a library. So in Ement.el[5], I've been using a simple Curl wrapper library that I've started.[6] It's rather primitive, but it seems to work well. It's relatively easy to use, IMHO. I haven't written documentation yet (other than docstrings), but you can see how it's used in the tests.[7] If it were useful, I'd be glad to contribute it to ELPA. Of course, it would be ideal if Emacs had a built-in HTTP library that didn't require an external dependency like Curl, but Curl does work well. The only issue I have with it is that certain data can only be passed via either the command line (leaving it visible to the whole system) or temporary files (which have to be carefully handled), which is a concern for, e.g. cookies, authentication tokens, passwords, etc. Unfortunately, when that issue was raised and a solution proposed in 2003, it was quickly rejected.[8] It's primarily that issue that has left me hesitant to advertise plz.el, because I wouldn't want to recommend that anyone use it for sensitive applications, even if the risk is probably minimal on one's personal system. Nevertheless, that issue remains in request.el when it uses its Curl backend, so it's not worse in that respect. Well, food for thought. :) Adam 0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20159 1: https://github.com/alphapapa/elexandria/blob/83a1b08d0711fdce07a5b33525535cc3a457c6ee/elexandria.el#L429 2: https://github.com/tkf/emacs-request/issues/112 3: https://github.com/tkf/emacs-request/issues/172 4: https://github.com/skeeto/elisp-latch/issues/1#issuecomment-397910988 5: https://github.com/alphapapa/ement.el 6: https://github.com/alphapapa/plz.el 7: https://github.com/alphapapa/plz.el/blob/master/tests/test-plz.el 8: https://curl.se/mail/archive-2003-08/0099.html