discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ML] Hosting of gnustep.org


From: Ivan Vučica
Subject: Re: [ML] Hosting of gnustep.org
Date: Tue, 19 Jan 2021 17:00:19 +0000

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.
Existing system works, and it'll keep on working, but I am neither
submitting software to the existing system or contributing changes to
it. 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.

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?

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

"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".

> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]