From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: ELPA submission: plz-see Date: Sat, 04 Nov 2023 15:56:28 +0200 Message-ID: <83o7g94o6r.fsf@gnu.org> References: <831qd56g4w.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38865"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, tomas@tuxteam.de To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 04 14:57:25 2023 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 1qzH9R-0009uB-8W for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Nov 2023 14:57:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzH8s-0000Ak-Ox; Sat, 04 Nov 2023 09:56:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzH8r-0000AB-3K for emacs-devel@gnu.org; Sat, 04 Nov 2023 09:56:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzH8q-0000aL-11; Sat, 04 Nov 2023 09:56:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IK9KNoe/76qKVoVXlyIZ9gzgiwILRTfl1A1+EsvMu+0=; b=rHqrQnEKYHaI JH6psvV0clRZxFxny5CWa9oaWpF6D8JiEvSdFiV9eHl5qGCKx00Cj4dqRM18qC1/oXOtJG7DP4Zga nxxir00j6shiCoOaKWv0JCnSOlBsTP4mRZA31fjovwQ1hNQQzPtLh89tpFM9Dy2F99wbVKEhGnJUK QxmPu5mqwqjffnxdOH9rf4S/sGiKK4+hoVKlksHur6JyAZSTgREe2oBuTiVfpE1JCepnwXniAAHEc 8B9RrrRyBTAEzdfMVGH9Yy9tqcZTkgVQHS1LXACM3qGe8OxULsFiFvQlYVpAysChdpD+GTmOOd844 HUv1WCIEe3FYKXqP4OwJsg==; In-Reply-To: (message from Adam Porter on Sat, 4 Nov 2023 08:30:47 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312210 Archived-At: > Date: Sat, 4 Nov 2023 08:30:47 -0500 > Cc: emacs-devel@gnu.org, tomas@tuxteam.de > From: Adam Porter > > > The claim is that fetching a URL with our built-in primitives is > > too slow. > > Forgive me, but that is not the claim. There are numerous problems > experienced with using url.el "in anger," as well as with other HTTP > client libraries for Emacs. Stefan K. was kind enough to link one of my > posts about this issue a few years ago, when plz.el was earlier in its > development (the issues mentioned having been solved now)[0]. Briefly, > the problems include unreliability (e.g. callbacks being called multiple > times or not at all, timeouts that don't happen), very awkward API (e.g. > having to let-bind often-undocumented variables to do basic HTTP > operations) These all sound like bugs, and I'd be surprised if bugs were cited as a reason to go to a completely different implementation, and one that is based on an external program on top of that. Bugs should be fixed; they should not cause us to throw away our code just because it has bugs. Especially since those bugs cannot be so bad, as our implementation of network communications does work: I'm sending this mail using it, for example. > and, perhaps also, inferior performance compared to a > curl-based implementation (curl being implemented in a separate process, > in C). So is performance an issue or isn't it? > I confess to feeling a bit annoyed at having to re-justify the inclusion > of plz.el in GNU ELPA (or, at least, I feel like I'm having to do so). This is a misunderstanding. I never said anything about inclusion of the package in ELPA or the need to justify it. I responded to the suggestion to integrate curl with the Emacs core: >> > > As has been said on emacs-devel several times over the years, the next >> > > significant step in this field would most likely be for Emacs to >> > > integrate libcurl directly. Maybe someday that will happen... Please don't misrepresent what I said and why, because the above sounds like you are saying I questioned your reasons for developing the package or asked you to explain why it was needed. I did not. > Having said all that, of course it would be best if Emacs's built-in > library were the best one. But as the author of url.el himself has > admitted, it has some fundamental issues which are not easy to solve, > and his own branch related to improving it hasn't been touched in 6 > years[3]. And so far, no one has stepped up to integrate libcurl or > similar. If url.el has fundamental problems, they can be fixed by thorough modifications or even with a completely new line of APIs which don't have those problems. That is not the issue that bothers me here; the issue that bothers me is the idea that instead of improving our own implementation, we should use an external program. It should be clear to anyone who understands how this stuff is integrated into the core that basing this on external programs has serious issues of its own, because Emacs is not a garden-variety program, it needs to support many low-level hooks into the communications level which are hard or even impossible with external programs and libraries. I very much doubt that going this way will ever be able to support everything we support now with network "processes" and applications based on them. It is indeed unfortunate that we don't have anyone working on these issues. I still hope that someone will step forward soon enough. > But the name is of very little importance, and surely no more > difficult to remember than an API, of which there are innumerable > ones in Emacs. My original request to find a better name was for plz-see, not for plz. So once again, please don't misrepresent what I said and why.