[Top][All Lists]

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

Re: [ML] Hosting of gnustep.org

From: David Chisnall
Subject: Re: [ML] Hosting of gnustep.org
Date: Tue, 19 Jan 2021 13:59:20 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

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:

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


reply via email to

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