- From: Luke Briggs <luke@kulestar.com>
- Date: Sun, 14 Aug 2016 14:44:12 +0100
- To: mofo syne <mofosyne@gmail.com>
- Cc: public-webassembly@w3.org
Hey there, Please keep this kind of suggestion over on Github rather than this (very large!) mailing list. As a quick thought though, I don't think this would work because of security; people won't want code from 3rd parties being uncontrollably included in their site. So something like: <script src='https://python.org/webRuntime.wasm'></script> <script type='text/python'> ...python here.. </script> Only involves one extra line and works without any centralized involvement which is overall better for openness anyway imo. All the best, Luke Briggs On 2016-08-14 14:21, mofo syne wrote: > What does this mean in practice for the average user if this idea is > implemented? It may mean that on the top of any html page, you should > declare what language dependencies your html uses (does it use C, > python, ruby, javascript, or dart etc...). This would prompt the > browser to check a package manager for the latest compiler/interpreter > that can understand these language. > > On Sun, Aug 14, 2016 at 10:32 PM, mofo syne <mofosyne@gmail.com> > wrote: > >> I am sure this has been thought of, but I haven't found this idea in >> google searches. >> >> What would be interesting, is if the web assembly >> infrastructure/standard provide some mechanism for automatically >> dealing with compilers/interpreters besides javascript. >> >> So much like having a package manager automatically download >> dependencies in linux. What may be useful is if there is a online >> repository of wasm binaries of interpreters and compilers for all >> the major languages in the web. >> >> What this would allow, is for users to insert source code into their >> website besides javascript, take for instance those who want to give >> dart programming language a shot. The major issues hampering >> experimentation with languages besides javascript is the lack of >> support of browsers for other languages. >> >> WASM helps solve the javascript hold over client side scripting, but >> at a potential cost to openness of the code. Hosting a common >> popular compiler infrastructure manager would encourage users to >> insert normal source code into their website besides javascript. >> >> Well that's my 5cents to the discussion. I'm sure this is not the >> only way to approach the aspect of making wasm more open to others >> that chose to be open. >> >> Cheers,
Received on Sunday, 14 August 2016 13:45:52 UTC