On Wed, 14 Jun 2023 06:30:04 -0400 bill-auger <bill-auger@peers.community> wrote: > 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 One issue here would be to understand how this webapp.html page is created. If it's simply an HTML page created by hand it there is only the usability issue left.
If not, packaging it properly might require significant effort, especially if there is a lot of dependencies (like some javascript minifier, some CSS compiler, etc). > 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) Another point of view would be to find and package software that is not disposable, like the one I mentioned (Joan Jump) which is under a free license and currently doesn't have other dependencies than a web server and browser. This makes solving the problem much more doable since there is only usability to take care of (and it's not easy to fix but it looks doable with a bit of effort / thinking / trial and error). > 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 Daemons have the same issue, but they typically use somewhat reserved TCP/UDP ports. And they usually don't need extra configuration in the client to work (like disabling fingerprint tracking, etc). Another way could be to patch the html file to have everything built in (like the JavaScript, the fonts, etc). Once done the browser configuration issue would need to be solved (for instance by shipping a profile just for that game, and finding a way to not disrupt the current browser usage). Denis.
pgpguVb3frmJq.pgp
Description: OpenPGP digital signature
