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: Re: ELPA submission: plz-see Date: Sat, 4 Nov 2023 09:38:06 -0500 Message-ID: References: <83o7g94o6r.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39012"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org, tomas@tuxteam.de To: eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 04 15:39:00 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 1qzHnf-0009uj-Ff for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Nov 2023 15:39:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzHmx-0003ui-3i; Sat, 04 Nov 2023 10:38:15 -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 1qzHmv-0003su-Om for emacs-devel@gnu.org; Sat, 04 Nov 2023 10:38:13 -0400 Original-Received: from slategray.cherry.relay.mailchannels.net ([23.83.223.169]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzHmt-0001xa-Dl; Sat, 04 Nov 2023 10:38:13 -0400 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 035E14C0D48; Sat, 4 Nov 2023 14:38:09 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a206.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AD1C74C0D02; Sat, 4 Nov 2023 14:38:08 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1699108688; a=rsa-sha256; cv=none; b=9JcFlndMYFuCuyxVodS3a8gnjsYA1WyToqDGJPqZnit8bRDiT8gqWyKlZY/+OAHkodKIAS 27+EdDoWb8/zcG50uf4AC2LezaA0R2DoTjW/mEFwJloG3H9nC0SCBm/32+k6dCpWxY5mRd 3FcVWntlPuURg2xN0IJ2OV4oU9Wo/Vj14lcZCdVXsgClRS6kdF0s4XHifXtQXtMEleLxQA akkCBHyWIAzmlkxNZNRl7Hb8vxk/k2KZ3pNw1c45dMNUTO5EK2/YdeoD9UImbaeQjE30Uq Pnubawv0vS/Hxt+spNZ/+D6umyPenA34CXWxLEPuhrlSefUDZoRoif7x7kui1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1699108688; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MlXSAZO5Hbaka8pU5+rKVHXP9u4gDYgM4qdbHFbDOnQ=; b=x+k7ca+PVr9prHhjvQ7weT99yNqurRQ/hQci3p0jfk3N8c2Saba/U7srKWXlLcMic9cj5J hEkgxuspL7toQjNOU61F/VyZo10lGIBHtwSvfLeuxBC0/mh7PSGvG97irk9bMnksC2HifL c25B6ICWgSTP+xkzjjNAbqQDK36cVxIXeT3useNhSHGecLANL6+n92xZ4GJGq3/hd3Qmyq 6FsvThBSU+cqQ6hFcLrqECsl8d4Mws+m8Kf8UopuaoyrpjXjIBupaqVlNxMWN8Z8/Gp9zs 1Rn2urHxNnsb/LS6dKhA80d4qkPJqvYdaFx9tZlouDMYlc8Vg2a6pCUuaMVJ+A== ARC-Authentication-Results: i=1; rspamd-7b5f9b5465-s7r4s; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Celery-Duck: 20ca39cf0e2da10f_1699108688837_1740394798 X-MC-Loop-Signature: 1699108688837:3614813276 X-MC-Ingress-Time: 1699108688837 Original-Received: from pdx1-sub0-mail-a206.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.104.29.54 (trex/6.9.2); Sat, 04 Nov 2023 14:38:08 +0000 Original-Received: from [10.43.2.102] (unknown [193.56.116.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a206.dreamhost.com (Postfix) with ESMTPSA id 4SN0b40YBWz6F; Sat, 4 Nov 2023 07:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1699108688; bh=MlXSAZO5Hbaka8pU5+rKVHXP9u4gDYgM4qdbHFbDOnQ=; h=Date:To:Cc:Subject:From:Content-Type:Content-Transfer-Encoding; b=Fyk/R5FOURqsylsLQlFEFNDv3S5ioXXBFl+D+W0WYox3LJKS2H4mAjlsQwYDP3sjK DljgJWDvQ0OJoYPXlSmxCac6HcRxNJ7Z5WjoCPu/VKQU3xIcvnpXOzoV7ezyrATOu0 3uEYfJHWD6sk9UfNClN4JF11Yu8HebvX3x/jDXtouTf7Ou1U0/caCkFOuOYYlXsP+s Q1eU4HvaxlgnMzcCA/+j+mY51phKaiujjJIfZOQNP+eHO/EEAQxXE7eamJXtC8U60O HTLBPDuUaUmXO6YREJvrma98DXu2koHVf6iPZFn2/pZV6T3FIpXpGDKbhP4BrIcvv5 Of6FdqGMlfApQ== Content-Language: en-US In-Reply-To: <83o7g94o6r.fsf@gnu.org> Received-SPF: neutral client-ip=23.83.223.169; envelope-from=adam@alphapapa.net; helo=slategray.cherry.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:312216 Archived-At: Hello Eli, >> 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. Ideally, of course, I would agree with you. In practice, experience has shown that fixing these bugs is not so simple. As even Lars said years ago[0]: "And the more I looked at this, the more apparently it became [clear] that Emacs' network stuff should just be totally reimplemented, because it's so full of... oddnesses geared toward processes. And processes and network connections are very different things. "So it's a Big Project. :-/" The file process.c is known for being hard to debug, especially with regard to these kinds of problems. I feel fortunate that I was able to, with the help of a few other people, work around them in plz.el to resolve issues with reliability. >> 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? As others have noted here and on the bug tracker, Emacs's built-in network processes seem to have hangs with regard to DNS, TLS, etc, and having the external curl process handle those issues avoids those problems. Some of this discussion happened three years ago, where even Richard suggested that using an external process like curl to solve it seemed reasonable.[1] >> 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. Forgive me, then, for misunderstanding you. It's never my intention to misrepresent. >> 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. Of course, I don't disagree with you. The fallback to an external program is a pragmatic decision, one which plz.el is in a long line of similar packages to make. > 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. Indeed, I misunderstood. Thanks for patiently clarifying what you meant. --Adam 0: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22921#19 1: https://lists.gnu.org/r/emacs-devel/2020-12/msg01456.html