GNU bug report logs - #69132
[ELPA] Remove jQuery from elpa.gnu.org

Previous Next

Full log

Message #74 received at 69132 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: Corwin Brust <corwin <at> bru.st>, 69132 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Thu, 22 Feb 2024 12:00:52 +0000

Richard Stallman <rms <at> gnu.org> writes:

>   > 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.

In this case, both options would be overkill.  The search functionality
does little more than just hiding a few elements from a table.  In
practice, it don't offer much more than using the built-in C-f search
functionality, that every browser provides.

[...]

> 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.

ELPA already has a format for listing packages in an archive, and just
like with browsers, it wouldn't really provide anything that M-x
list-packages and C-s doesn't already do.

> (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 <what?>), and giving them a
> link to it.

We should be talking about the same code; I am not sure what you mean by
instructing users to install the code themselves?  Are you talking about
user-scripts?

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.