> Am 19.01.2021 um 14:59 schrieb David Chisnall <[email protected]>: > > 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
