Re: [ML] Hosting of gnustep.org

[David Chisnall]

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.

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

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

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

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

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

The simplest solution is to turn off the GNUstep Software Index.  That's 
the zero-effort solution.  There are then two alternatives:

 - Someone volunteers to maintain the infrastructure.
 - Someone volunteers to rewrite it to use cheap instead infrastructure.

David