Re: [ML] Hosting of gnustep.org

[H. Nikolaus Schaller]

> Am 19.01.2021 um 18:00 schrieb Ivan Vučica <ivan@vucica.net>:
> 
> On Tue, Jan 19, 2021 at 12:58 PM H. Nikolaus Schaller <hns@goldelico.com> 
> wrote:
>>> I realise that some people dislike JavaScript, but in 2021 I think that 
>>> battle is probably lost.
>> 
>> No I don't dislike it at all - but why do a new solution if one exists?
> 
> To my understanding, the current solution requires running a system
> with both PHP and MySQL installed. This means we need a sysadmin.
> Honestly, I currently don't even know who's running the machine where
> PHP and MySQL required for /softwareindex/ served on gnustep.org. I
> don't know where it's deployed. I don't know how to make the change.

You may be astonsihed that even I don't know. I may have to dig out the
10 years old mails.

It did not need any maintainance in between. But it could be copied to
any Linux host with apt-get install apache2 php mysql in ca. 30 minutes.

And run for another 10 years.

> Existing system works, and it'll keep on working, but I am neither
> submitting software to the existing system or contributing changes to
> it.

Why not?

> Moving off of it means less maintenance for whoever's running
> machine underlying gnustep.org, and easier contributions by people who
> can write Markdown, but not necessarily want to touch PHP.

Nobody needs to write PHP (except me as I have written the original
code).

> Don't forget: to properly contribute to softwareindex, I'd have to
> create a local working environment containing PHP (and a frontend
> server, due to how PHP deployments work), containing MySQL, create the
> underlying database and populate it with stub data, make the
> contribution, and hope it all works. Can I just hack away at PHP and
> hope for the best -- i.e. "test in production"? Sure. I did that
> plenty of times. I edited prod and committed the result of the edit.
> Would you consider that as a good software engineering practice?

You as the user do not need to work that way. Like on Wikipedia you
do not get into touch with the MediaWiki code (which is also PHP + MySQL).

You just type content into the web form and press the submit button.

> Storing a list of software in a version control system seems like a
> much simpler solution.

That is probably a misconception. The database *is* a version control
system. Just not git.

> 
> "It already exists" is an easy answer ignoring the question "who has
> the backups, who can create the backups, who can approve the changes,
> who can fork the site, and who maintains and pays for the existing
> system".

There are answers, but nobody has asked yet.

> 
>>> Using a database or any server-side scripting seems massively 
>>> overengineered for this.
>> 
>> No, it is not over engineered. It is already done! And is standard 
>> technology. Look for example at Joomla, MediaWiki, NextCloud etc. They all 
>> do the same. Some mix it with JavaScript to make some user interactions 
>> smoother.
> 
> I've done plenty of work like this, and I am happy to run a SQL
> database for myself when appropriate.
> 
> But this is in situations where I don't have external contributors.
> 
> I don't want to give external contributors access to the database, and
> I don't want to request access to someone else's systems.
> 
>>> I've seen this scale to projects with hundreds of contributors, I don't 
>>> imagine GNUstep having problems with it.  Looking at that index, it appears 
>>> as if it averages less than one update per month currently.
>> 
>> Ok, I see you want to invent something completely new instead of thinking 
>> about how to easily move the existing.
>> In my experience, such proposals will rarely be completed because it is 
>> possible to use the new technology, but it takes far more time than simply 
>> continuing to use the old.
> 
> Static documentation sites edited via version control systems are
> absolutely normal today.
> 
> And adding minimal interactivity via Javascript is the very reason why
> Javascript came to be in the nineties.

Yes, I know the history. And because JavaScript has limitations there
is still a lot of server-side activities. And PHP and MySQL became the
standard after that.

BR,
Nikolaus