From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.bugs Subject: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org Date: Tue, 20 Feb 2024 21:56:24 -0500 Message-ID: References: <87jzn6g7ep.fsf@posteo.net> <87h6iap2lz.fsf@posteo.net> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27229"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, 69132@debbugs.gnu.org, monnier@iro.umontreal.ca To: Corwin Brust Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 21 04:00:04 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rccq4-0006rx-8G for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Feb 2024 04:00:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rccpi-0000Bb-O5; Tue, 20 Feb 2024 21:59:42 -0500 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 1rccph-0000B7-6c for bug-gnu-emacs@gnu.org; Tue, 20 Feb 2024 21:59:41 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rccpg-00070N-Ue for bug-gnu-emacs@gnu.org; Tue, 20 Feb 2024 21:59:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rccq2-0005i0-UE for bug-gnu-emacs@gnu.org; Tue, 20 Feb 2024 22:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Feb 2024 03:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69132 X-GNU-PR-Package: emacs Original-Received: via spool by 69132-submit@debbugs.gnu.org id=B69132.170848435021862 (code B ref 69132); Wed, 21 Feb 2024 03:00:02 +0000 Original-Received: (at 69132) by debbugs.gnu.org; 21 Feb 2024 02:59:10 +0000 Original-Received: from localhost ([127.0.0.1]:47502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rccp8-0005gU-Hv for submit@debbugs.gnu.org; Tue, 20 Feb 2024 21:59:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rccp5-0005g0-VI for 69132@debbugs.gnu.org; Tue, 20 Feb 2024 21:59:05 -0500 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 1rccmX-0006fL-2z; Tue, 20 Feb 2024 21:56:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=FDC4zUBkHsPSd9evS15E2vkUJ93CFm00GqbipMlkhTc=; b=qC1gdaYMfVQp j5SFH5/ok3a0BfWpRokjZDqTNrTZeAlFtlA5aGS2EE4C+8ToPZ5IYcxeon6qjB/UZOlch6FHRqzqG NZGpVA4ocYBmjZVBZQAPetV8+G/gG8AwYJvVbNep8dH13ow4lvf7rc7z1m9EvTTYPGnnKqHNtslEx YNPC3M9JkvpCQSkdvtNt29dF0ChuIB+CAB4GhAKxpbbyHCVFitnaRsgLEs0Ns0e08XEIdCh7/KB8M qWueB4UTbulkm8rLrEQS+hNf0DXX0Sfys5z8SVWFQGxlg2KI25EY3gZ7MXibttp+4+R+KdH9FgfKc KtnBJw9S9stMcMxHxC7IPg==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rccmW-0006Hb-KR; Tue, 20 Feb 2024 21:56:24 -0500 In-Reply-To: (message from Corwin Brust on Sat, 17 Feb 2024 22:07:56 -0600) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280370 Archived-At: [[[ 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. ]]] > Given someone thought they'd use it, we could add an additional option > (radio button, or smth) that would case the search to happen on the > server instead of via client-side script. In moral terms, we should avoid Javascript code entirely whenever possible. Avoiding it should be the default. > That said, there are > several reasons I feel it would be tragic to /replace/ a client side > function with a server side one, in this case. The word "tragic" is surely too strong. It is rare that practical inconveniences are so bad as to justify that word. In computing we are surrounded by injustices, by systems that do wrong to the users -- let's reserve the word "tragic" for them. > As stated: I think it is *not* possible to perform this type of > "client-side" search without using Javascript. There are two fully moral ways to implement a search feature for a web site. One is to implement it inside the web server. The other is to communicate with a free program that the user has installed in per computer, and could replace with any other. When the server sends Javascript code to the user, even free Javascript in the form of source code with comments, what normally happens is that the browser runs the code that it was sent. It is possible for users to change that code, and even save their changed versions, but it requires using obscure features and understanding a language rarely used for anything but web development. Also, this is fragile -- if the site changes its search code, the patches are likely to break. > It would likely be > simple to create a search program on the web-server, however in this > case that actually makes it slightly harder for users to see the > search code involved It is normal for servers to format and select data for presentation, sometimes offering options about how to do it. There is nothing wrong with that. > In fact, this often means a user can, in addition to viewing and > saving the sources, use the javascript console and other so-called > "developer tools". Developer tools are provided in some form by a > variety of popular browsers such as Firefox and the Chromium line, > among others. They can be useful if you know Javascript (I don't). But it is always fragile. Site developers will change the layout of the contents and change the Javascript code at the same time. Users' saved patches won't work after that. If you patch Emacs, and the code in the next Emacs version is different so your patch does not work in it, you can keep using your patched old Emacs until you have time to rework the patch. (Or forever.) But if the Javascript in a web page changes, along with its data layout, there is normally no way to get the current data in the old layout so your old patch will work. We could overcome this wih a documented API that users could optionally use for ELPA search. It would provide the package list data in a form convenient for programs. Users could write their own code, in Javascript or in some other language, to operate on the API output to customize the search as they like. This would provide the benefit you call for, in an even more general way. (Is there a semistandard web convention for specifying API versions so you can say, "Give me this data in the format we used in June 2022"?) Meanwhile, the rest of us, we who don't use that API, would not be asked to run any code straight off the web server. In a later message you said this: > As the entire functionality it provides is just an optional, superficial > enchantment (one that I almost never use), I don't think this is worth > pursuing. All the ways I can imagine to achieve this would be less > convenient hacks. Assuming you're talking about the same Javascript code, how about directing users to install that code into their browsers themselves (if they want this optional, superficial ), and giving them a link to it. That would avoid the moral problem of Javascript sent implicitly to browsers, and these few users would have only a little work to do to set it up. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)