Re: FSD as a Git repository

[David Hedlund]

I suggested a public API for the FSD at
https://directory.fsf.org/wiki/Free_Software_Directory:Infrastructure#Public_API
-- Thanks Bone Baboon!

On 2021-07-18 00:30, Bone Baboon wrote:
> 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.
>