Re: [ML] Hosting of gnustep.org

[H. Nikolaus Schaller]

> Am 19.01.2021 um 14:59 schrieb David Chisnall <gnustep@theravensnest.org>:
> 
> On 19/01/2021 12:57, H. Nikolaus Schaller wrote:
>>>  Given that this is searching from under a hundred things, all of which can 
>>> be downloaded in a single HTTP request quite cheaply, you could do that 
>>> client side in less than one network round trip time.
>> And you can click the "Anything wrong with this entry? Click here to fix 
>> it!" button at the end of the page allowing to propose new version or add 
>> screen shots. Tell me how that should work.
> 
> It would link to the source page on GitHub and ask people to raise a PR.  How 
> many of these updates do you get currently?
> 
>>>> How can you make pages that can be sorted/filtered dynamically on 
>>>> user-request?
>>> Normally, with client-side JavaScript.
>> What is your norm?
> 
> I don't understand the question.

If you declare something as "normally" there must be something where you gauge 
your statement.

> 
>>>  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?
> 
> I think that's what I'm asking.  Jekyll lets you build something

I don't want to build something new. If you want, please go ahead.

> with the same user experience, with no requirements on anything other than a 
> static web host.  A dynamic web host imposes a nontrivial administrative 
> burden for maintaining security (especially something using PHP).

No. PHP is not insecure per se - only if it is wrongly used.

> 
>>> There are off-the-shelf JavaScript things for sortable / filterable / 
>>> searchable tables, I quite like this one, which gives you a single .js file 
>>> and falls back to a non-sortable table gracefully if JavaScript is disabled:
>>> 
>>> http://www.kryogenix.org/code/browser/sorttable/
>> Yes, I know - but why choose a new solution if one exists?
> 
> Yes, exactly.  Why roll your own when there are off-the-shelf things that do 
> what you need?

SWI is on the shelf for ca. 8 years. PHP, MySQL as well.

> 
>>> I don't seem to be able to sort the table with the live version and the 
>>> filter by OS and Model boxes let me filter by Any, with no other options in 
>>> the drop-down.
>> Yes, that is because there is only a single category for these values.
>>> Making the filter box work on the summary table is pretty trivial, just 
>>> iterate over the table entries, hide (set the hidden property in the DOM) 
>>> any table rows that don't match the search term.
>> That is exactly what the SQL select behind is also doing.
> 
> And requires someone to pay for host an SQL database and someone to be 
> responsible for security updates.

I am not aware that we did pay anything for PHP and SQL database of the swi in 
the past 8 years. Why should that change?
All of this is FLOSS. Just apt-get it. To get security updates.

> 
>>> 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.
> 
> These are all big CMS or web app systems, they are very different from a 
> mostly static web page.
> 
>>>  If the software index grows to have thousands of entries, I'd change my 
>>> mind, but the complete data for the summary table is likely to be a couple 
>>> of K and so you're likely to need more network traffic for boilerplate on 
>>> multiple page requests with the same template than you save by filtering 
>>> the contents on the server.
>> That may be true, but is even a counter-argument against your ideas: if it 
>> is just some K (hence not wasting resources), why do a complete rewrite of 
>> it (not to forget debugging) a working solution? This would waste other 
>> resources, i.e. developer's time.
> 
> Because maintaining a dynamic web server that is backed by a database costs 
> time and money over an unbounded time.

It looks like you are just doing theoretical arguments. The SWI is up and 
running for ca. 8 years and did neither cost time or money.

> 
>>>> How can you make a page with user-generated change requests send out an 
>>>> e-mail to reviewers for approval?
>>> I wouldn't.  Folks that want to update it can raise a GitHub PR that has 
>>> their new Markdown file in it.  They can install the github-pages Ruby Gem 
>>> and run jekyll-serve locally to test how their changes will look before 
>>> submitting.  GitHub automatically sends emails about PRs to all maintainers 
>>> of a project.
>>> 
>>> 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.
> 
> The start point is that Gregory does not wish to continue paying for and 
> maintaining the infrastructure.

I had asked but not got an answer how much it did cost. Btw. there was just an 
offer to host the websites and everything, apparently for free.

>  I am 100% sympathetic with that, because it is doing nothing that cannot be 
> done with zero-cost solutions that tens of thousands of other projects use.

Please go ahead and provide a replacement in time. But do not and never expect 
that *I* am endorsing or doing that.

> The simplest solution is to turn off the GNUstep Software Index.  That's the 
> zero-effort solution.

Well, if you do arguments on this level, I'd suggest something else: shut down 
gnustep.org. That is the real zero-effort solution. Now I start to understand 
why we could indeed need a code of conduct...

>  There are then two alternatives:
> 
> - Someone volunteers to maintain the infrastructure.
> - Someone volunteers to rewrite it to use cheap instead infrastructure.

There is option 3:
- Someone migrates existing SWI on cheap (or free as in free beer) 
infrastructure and takes care that it can still be accessed from 
http://www.gnustep.org/softwareindex