Re: [ML] Hosting of gnustep.org

[H. Nikolaus Schaller]

> Am 19.01.2021 um 15:14 schrieb David Chisnall <gnustep@theravensnest.org>:
> 
> On 19/01/2021 13:09, H. Nikolaus Schaller wrote:
>> BTW: I forgot to mention that we already have a GNUstep way of storing all 
>> this metadata:
>>      http://www.gnustep.org/softwareindex/plist.php
>> The idea behind this is the recently mentioned GAPstore.app which would 
>> allow to show
>> the same application list as a full app on the GNUstep desktop, filter out 
>> applications
>> already installed and notify about updates. Like you know from iOS or Google 
>> Play.
> 
> NSJSONSerialization was added to GNUstep ten years ago.  We don't need to 
> have a custom format for this, we can use the same format that most web 
> things use for interop.

Yes, can also be JSON. I always was unhappy that the open source community 
reinvented the same thing twice (JSON, YAML) what OpenSTEP already had as 
property lists.

But you are again discussion on a different level as somebody who is making a 
concept for a new green-field implementation. Then we can discuss about data 
formats etc.

But we have a working solution. Debugged. Working. Maintained (which isn't much 
work). Functions. Doing what it was designed for.

Zero need to develop anything new. Only keep it running because the web server 
should be moved.

> 
>> If you think a little further there could be a mode to edit entries locally 
>> and send them
>> to the central database for doing announcements of new applications or 
>> versions.
> 
> And if you think about that more, now you need to either provide account 
> management, authorisation, access control, and a load of other complex things 
> such as handling spam (maybe not from GAPstore.app itself, but from other 
> things where malicious folks decide to use the APIs that you've created for 
> GAPstore.app).

Sure.

> 
>> All this becomes impossible or at least brain-twisting if there is not a 
>> central database
>> but static HTML+JS+CSS pages.
> 
> You are conflating a great many things here:
> 
> - Storing in MySQL versus in flat files.
> - Generating the HTML once whenever the data store is modified, versus on 
> every request.
> - Exposing a machine-readable version of the data versus generating only 
> presentation HTML.
> - Providing a rich set of APIs for accessing the data store.
> 
> The first three are orthogonal and *nothing* about any of those choices 
> prevents what you want to do.  I'm not even going to touch the last one, 
> because doing it securely is such a massive engineering undertaking that I 
> don't think anyone on this list is going to devote the effort required to do 
> it.

But you are undertaking to write a completely new replacement? Are you? Are you 
really? When can I test a prototype?

If not, then please shut up deciding what tools other people should use in our 
opinion.

> 
>> So it completely breaks the philosophy and goals of the software index and 
>> stops it from
>> ever becoming something like the macOS app store or Google Play.
> 
> I feel like you're changing the problem a lot now.

I feel you are discussing a different topic and I just try to explain.

>  The original problem was can we present a web interface listing the programs 
> using GNUstep with a nice UI and expose the same data to other non-browser 
> consumers in a useful way, with updates being easy for people to submit, with 
> a free off-the-shelf static site generator.  The answer is 'yes, without too 
> much effort'.

Indeed. Yes, I have added to explain the original idea and strategy behind the 
software index.

So far I only asked that it should not be forgotten to move along and find 
myself in a discussion about the general merits of the software index.

> 
> Now you're saying 'can we extend this to provide a solution that is 
> equivalent to a commercial project that cost millions of dollars and needed 
> incredibly careful security work (which both Google and Apple managed to get 
> wrong at least a few times), oh, and while we're there, can we make it 
> multi-platform please?'  The answer to that is, 'no, a static site generator 
> can't do this, but given that it's a huge engineering project anyway, the 
> JSON that it generates or the files in the git repo could easily be the 
> canonical data source until something better comes along'.

No, I am not saying 'can we extend this...' but I say 'we can extend this to 
equivalent to a commercial project that cost millions of dollars' at much lower 
effort (because I believe we are more clever than multi-milions). Almost for 
free. Because we have done the right start.

But again: are you committed to do this migration to your proposal of static 
pages? Are you writing the new Jekyll and JavaScript code?

What I don't like are people who disrespect the work invested by others to 
provide a working solutions and have thousands of reasons why it should be done 
differently. Some may be valid, some simply do not fit into the overall 
picture. But if it comes to real work, they contribute nothing, but have killed 
something which already exists.

Others accept that there is a solution and try to be helpful to make it better. 
And help to maintain the existing solution and make it better in small steps.

To which group do you belong?

Now, I think I have said everything what can be said here.

Summary: I just want that the software index is not forgotten when moving 
gnustep.org to a different server, not that it is rewritten from scratch.