unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
To: Corwin Brust <corwin@bru.st>
Cc: philipk@posteo.net, 69132@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#69132: [ELPA] Remove jQuery from elpa.gnu.org
Date: Tue, 20 Feb 2024 21:56:24 -0500	[thread overview]
Message-ID: <E1rccmW-0006Hb-KR@fencepost.gnu.org> (raw)
In-Reply-To: <CAJf-WoSm9SFp+=CidsDncbjR+iMV3XfST+Rju45TmKZsWiBBLQ@mail.gmail.com> (message from Corwin Brust on Sat, 17 Feb 2024 22:07:56 -0600)

[[[ 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 <what?>), 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)







  parent reply	other threads:[~2024-02-21  2:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 19:41 bug#69132: [ELPA] Remove jQuery from elpa.gnu.org Philip Kaludercic
2024-02-14 23:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-15  8:12   ` Philip Kaludercic
2024-02-15 11:07     ` Philip Kaludercic
2024-02-15 15:37     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 18:25       ` Stefan Kangas
2024-02-17 20:57       ` Dmitry Gutov
2024-02-17 21:04         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:26           ` Dmitry Gutov
2024-02-17 22:44             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 22:49               ` Dmitry Gutov
2024-02-18  4:05                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 12:14                   ` Dmitry Gutov
2024-02-18 14:13                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 14:24                       ` Dmitry Gutov
2024-02-18 14:37                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 14:38                           ` Dmitry Gutov
2024-02-18  3:28       ` Richard Stallman
2024-02-18  4:07         ` Corwin Brust
2024-02-18  4:20           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-21  2:56           ` Richard Stallman [this message]
2024-02-22 12:00             ` Philip Kaludercic
2024-02-25  3:13               ` Richard Stallman
2024-02-25 10:55                 ` Philip Kaludercic
2024-02-25 15:18                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 15:07         ` Philip Kaludercic
2024-02-18 18:19           ` Corwin Brust
2024-02-24 10:03 ` Philip Kaludercic
2024-02-25 10:06   ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-25 10:44     ` Philip Kaludercic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1rccmW-0006Hb-KR@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=69132@debbugs.gnu.org \
    --cc=corwin@bru.st \
    --cc=monnier@iro.umontreal.ca \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).