Re: FSD as a Git repository

[Bone Baboon]

Lorenzo L. Ancora via writes:

> I suggest that it is useless and unmaintainable in the long term to
> support text-only web browsers and/or those that do not implement
> JavaScript. Not your fault, it is how the World Wide Web was designed
> and will be developed.

HTTP can serve web pages that are just HTML and CSS with no JavaScript.

There are other protocols in addition to HTTP that do not use
JavaScript.  Such as Gemini and Gopher.

> 1. JavaScript is required ( -- technically unavoidable -- ) to
> implement accessibility and interactivity in complex, modern
> websites. Literally, at some point you will always be forced to use
> it, because scripting is very often necessary;

A read only HTML and CSS version of the FSD could be served without
JavaScript.

Changes to the FSD contents could be managed with a Git repository and a
Git workflow using email and patches.

> 2. Server-side alternatives to some functionalities typically offered
> via JavaScript do exist but, since HTTP/S is a stateless protocol,
> they almost always cause high server load and extend the attack
> surface. Furthermore, the security requirements of the FSF would
> impede the FSD administrators from managing server-side code;

This concept of the FSD as a Git repository replaces the client side
JavaScript and equivalent server side code with the use of a Git
repository, Git workflow and rendering the source code to HTML.

> 3. Nowadays, text-only does not mean more accessible, quite the
> opposite: HTML 5 conveys semantic information via semantic tags; CSS 
> conveys semantic information through visibility and appearance rules;
> the combination of JavaScript and CSS 3 offers the ability to detect
> the features of the web browser and adapt the web page dynamically.
> That info is required by physically and/or mentally impaired users.
> Text files does not offer any kind of aid in navigation, visualization
> (no branching logic = no ability to adapt), SEO (nowadays search
> engines interpret the meaning of the tags) and maintainability (no
> Content Management System = more hard work). Using Markdown won't make
> them more accessible, it will only make them awkward for TTS/Braille
> software, which is very bad;

To clarify I am suggesting that the source code would be compiled to
HTML and served with CSS so that people can browse a read only version
of the FSD.  This preserves the semantic meaning for people browsing a
read only copy of the FSD that is being served.

Someone would have the freedom to browse the read only FSD HTML contents
with whatever software they want.

> 4. Not all users are command-line savvy and can use Git, Bazaar,
> Breezy, CVS, ... without risking cause damage to their system or
> personal data by overwriting files or accidentally storing hidden
> directories alongside their backups.

To mitigate this a detailed tutorial on how to use Git to contribute to
the FSD could be provided.

> Speaking of privacy, for a user it is more difficult to delete the
> history of a terminal than to clear the browser history or use the
> private browsing mode;

Someone would have the freedom to browse the read only FSD HTML contents
with whatever software they want.

> 5. The number one rule of SEO is to never duplicate your content,
> because search engines are not made by idiots and will penalize all 
> domains and subdomains which host non-original/cloned contents,
> especially text. This means that you will inevitably lose users each 
> time you decide to duplicate your content;

This point should be taking into consideration when planning the
structure of the FSD Git repository and how it is rendered to HTML
pages.

> 6. Git (and really any other VCS) can be used to aid in hosting entire
> websites, but only if those websites are not managed by many
> people. The reason is that those systems are designed to allow
> per-file downgrade and will store a lot of ever-growing data. This
> works like a charm for small websites (guess what, I use them too!)
> but what happens when you need to store the continuous contributions
> of hundreds of users? You have hundreds of commits and changes, which
> will cause the size of the repository to grow rapidly, reducing the
> performance, making it almost impossible to efficiently diagnose
> problems and finally you will be forced to truncate the entire
> repository;

Git seems to be working well for many free software projects including
large projects like the Linux kernel.

If this problem arose then an archive Git repository could be created
and a new repository (truncated) could be used moving forwards.  This
approach could also be used if in the future it was desirable to migrate
to another version control system.

> 7. ...you will then need to implement server-side checks for the
> consistency of the repository, nullifying any performance gain and,
> even worse, creating increasingly heavy loading spikes on the server;

In this concept I am describing the server would be required to:
* compile the source code to HTML
* serve a static website of the source code repository (stagit or cgit)
* serve a static website for browsing a read only version of the FSD
  * source code compiled to HTML 

> 8. Because of the loss/approximation of positional (layout)
> information caused by the triple format conversion (HTML [manual] ->
> text [manual] -> folded CLI text [automatic) ) you may inadvertently
> convey bogus information to end users, so you will need someone
> competent to check every single file in the repository
> continuously... and you cannot afford that, because this is not a work
> for volunteers. This happens because all web pages are written with a
> combination of the WYSIWYM and WYSIWYG approaches, not good for
> downgrades;

I do not see the need for a triple conversion.

Source code compilation:
Plain text -> HTML

Where the plain text could be markdown or org-mode format for example.

> 9. Only trusted users should even ever have write access to a
> repository because in general a VCS lacks the ability to manage user
> rights, making user management, security audit and information
> verification very complex.

Yes this concept of the FSD as a Git repository would have people who
have commit access the the FSD Git repository reviewing submissions.

> Also, it should be noted that some users for the sole purpose of
> "showing their support for free software" declare that they usually
> use text-only browsers or disable JavaScript. However, this is
> unrealistic, because all banking sites, most social networks and in
> general most websites require the use of graphical browsers and
> JavaScript. So these statements are solely due to social pressure and
> such users certainly have the ability to use a modern graphical
> browser.

Banking can still be done by walking into a bank branch.

Not everyone uses social media.

People can choose to avoid websites that do not work without
JavaScript.

> Actually, MediaWiki is already the best choice and nothing more is
> required to offer an excellent user experience to 98% of your end
> users.

You should not dismiss people who are using text browsers because they
are outnumbered by people using graphical browsers with JavaScript.

> The only correct way to allow access to the FSD for the narrow
> minority of users using text-only web browsers is to create an ad-hoc
> web service with the help of a good full-stack web developer.

Another option that is mention by Bill Auger in this thread is use the
MediaWiki API.

> PS: Gopher and other exotic/ancient protocols require dedicated server
> software and proper isolation to be used in production.

Yes other protocols require different servers.

A benefit of this FSD as a Git repository concept is that it is
flexible.  If in the future it was desirable to serve the FSD over
another protocol it could be done by compiling the source code to a
format that the new adopted protocol serves.