Re: [GNU-linux-libre] Packaging JavaScript games

[bill-auger]

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