On Tue, 13 Jun 2023 18:53:27 +0200 Denis wrote: > One of the issue here is finding how to properly package and integrate > such games in FSDG distributions. A way could be to package the HTML > page and somehow find a way to properly launch a browser to play the > game.
agreed, that is a very good point - packaging for usability is a big concern i could have mentioned that there are a few examples of popular web "apps" which have done this; but their user-friendliness is not great - the 'element-web' package comes to mind - as i remember, the only way to use it (and i had to deduce this myself), is to open a web browser and browse explicitly to the file-system path, like: file:///use/share/web-apps/package-name/webapp.html - not very user-friendly unfortunately, i suspect that the problem of disposable software would remain, for the more complex javascript applications - regardless of which files you have locally installed, it is likely that they are designed to constantly pull novel ephemeral scripts from the network and execute them blindly - so those local files may not always be a complete solution - they may be only boot-strapping your way back to the original problem (merely "kicking the can down the road" a step) for applications of that sort, the developer would have needed to have the goals of verify-ablilty and hack-ability in mind all along (ie: the application would not be of that sort in the first place), or may need to re-design the client<->server protocol entirely, with this new perspective in mind (eg: transfer only data, not code nor presentation details - ie: mind the OSI networking layers) there appears to be a trend toward placing the server (or worse, the cloud) at the application layer, with the web browser as a dumb "thin client" - it is an inversion of the conventional client<->server design, where the server controls only the data, and the client manages everything else, entirely at the behest and whims of its user people accepted this back when web servers typically sent only HTML and possibly a humble amount of scripting for the purpose of dynamic display, but sent it only once in a batch, and almost _never_ sent _anything_ back to the server without the explicit intention of the user - this is no longer negligible, now that we have websites which are actually full-blown javascript applications, in two-way communication with, and executing arbitrary orders from the server continuously - libre or not, the web is a huge loop-hole, bypassing all four freedoms if the application is running locally, then the server has no business dictating the presentation or application behavior - naturally, that is regardless of the programming languages used - native client<->server application (such as mumble, email, and IRC) typically do not forget such well-established CS/networking concepts; but javascript devs seem to have no notion of them - it is assumed that the server dictates all aspects of the user experience, and clients should follow the server's arbitrary "orders" - hence -> loss of software freedom for everyone save the server operator On Tue, 13 Jun 2023 17:07:35 +0000 Denver wrote: > On Tue, Jun 13, 2023 at 06:53:27PM +0200, Denis 'GNUtoo' Carikli wrote: > > Another could be to somehow serve the html files and generate a web > > page that points to the all the installed games and expect users to go > > to that web page (http://localhost). > > local web development (including for JavaScript programs) has become much > more difficult due to browsers being hostile to it also, it is not such a great idea for any package to install, configure, and launch a web server automatically - that machine may not have any firewall for example - i would be looking for solutions such as 'element-web', which can launch exclusively from the local file-system, via the file:// protocol; and only then, collaborate with a server, local or remote - though, i suspect that many javascript applications, as written, would offer at least some resistance to that use-case
