[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 14:14:28 +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 13:09, H. Nikolaus Schaller wrote:
BTW: I forgot to mention that we already have a GNUstep way of storing all this 


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 
already installed and notify about updates. Like you know from iOS or Google 

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.

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

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.

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

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


reply via email to

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