Re: FSD as a Git repository

[Bone Baboon]

bill-auger writes:

> FWIW, mediawiki has a complete REST API - it can be accessed from
> the command line with curl, etc

Thank you for mentioning MediaWiki's API.

Has the FSD's MediaWiki API been made publicly accessible?

If the FSF has not made the FSD's MediaWiki API publicly available
yet then it would have to consider if it wants to make the API public
and maintain it.

I asked some question in #mediawiki@libera about MediaWiki's API.  These
links for the API documentation where shared:

<https://www.mediawiki.org/w/api.php>
<https://www.mediawiki.org/wiki/API:Edit>
<https://www.mediawiki.org/wiki/API:Main_page>

There is also an in development REST API that has "much less
functionality": 

<https://www.mediawiki.org/wiki/API:REST_API>

> all of the discussion so far has the regrettable presumption, that a
> web browser is required to read/write data to/from the internet, or to
> do so in an "accessible" way

In the first email of this thread when I described the concept of the
FSD as a Git repository I said one of the advantages was:

> * A text web browser would be optional.

This generalizes to:
* A web browser (of any kind) would be optional.

Someone could interact with the FSD if it was a Git repository without a
web browser and using free software by:
* Cloning the repository
* Browsing the plain text files locally
* Making changes locally
* Submitting patches with changes for the FSD repository
* Discussing FSD topics using IRC and email

When the entire workflow can be done on an individuals computer outside
of a web browser they can choose the free software that meets their
accessibility requirements.

> API clients are easy to write; and there are clients made for
> mediawiki already (weboob alone, has multiple plugins for
> mediawiki) - AFAIAC, that would satisfy the text-only use-case,
> just as well as gopher or anything else would, but without
> replacing the wiki, migrating all of it's data, or even patching
> any upstream code - the FSF would only need to enable API
> access, if it is not already

When I asked about MediaWiki API clients in #mediawiki@libera:
* this link was shared <https://www.mediawiki.org/wiki/API:Client_code>
* someone suggested pywikibot

I also spoke to the maintainer of mediawiki-el an Emacs MediaWiki
client.  The only Emacs MediaWiki client I am aware of that is free
software.  They told me that there are know undocumented bugs in
mediawiki-el and that it's configuration and use are not documentation.

> if some web service has a complete remote API, that is already
> the ideal option for text-only, no-js, accessibility, etc - an
> API is fully accessible by its nature (no colors, no mouse
> buttons to locate, etc)

A publicly accessible API with API clients has many of the same
advantages as the concept of the FSD as a Git repository.  They both
share the advantages of:

* Text only
* No JavaScript
* Accessible

The FSD as a Git repository concept requires less maintenance, is
simpler and is more resistant to changes.

# Less Maintenance

The FSD as a Git repository would be easier to maintain than MediaWiki.
It would replace a PHP web application, database and MediaWiki API with
a Git repository, two static websites and some simple automated scripts
to run when a commit is made to the repository to update the static
websites.

The FSF recently decided to use the Libera IRC network instead of
running it's own IRC network.  Part of the rational was that it did not
want to spend it's limited resources on maintaining an IRC server.

This FSD as a Git repository concept allows the resources that are going
into maintaining the FSD MediaWiki application to be redeployed.

# Simpler

There are several ways the FSD as a Git repository is simpler:

* Plain text file and a directory structure instead of a database for
  data storage.
* Git instead of the MediaWiki API or web browser for data transfer.
* Free software of the users choice instead of the MediaWiki's web user
  interface or API for browsing the FSD's contents.
* Free software of the users choice instead of the MediaWiki's web user
  interface or API for making edits
* Git and email or IRC instead of the MediaWiki's web user interface or
  API for submitting changes
* Collection of free software tools that are specialized (Unix
  philosophy) instead of the monolithic MediaWiki web application

# Resistant to change

For the FSD as a Git repository concept if any tool in the process was
no longer being maintained and stopped working it could be easily
replaced with another tool as all the tools used have multiple free
software alternatives.  The same simple substitute applies to the plain
text format.

If MediaWiki stopped being maintained it would not be as easy to
substitute an alternative.

> in short, the best javscript is 'none', and the best web browser
> is 'none' - no need to re-invent the wheel - mediawiki already
> supports it

I agree that a solution that does not require JavaScript or a browser is
desirable.

I would not call the transition of the FSD from MediaWiki to Git
reinventing the wheel.  I would call it data migration.  This raises the
question of what MediaWiki provides for data export options.