ikzann
Member
I have been playing around with support for scripting in other languages. I have a preliminary version of JavaScript support working, based on Mozilla's Rhino project. If this ends up getting merged, I think this will enable some pretty cool things - like using modern web frameworks to build relay scripts, or by allowing easier programming of complex data structures and algorithms.
In the current draft, access to the ASH runtime library is available via an "ash" global in JavaScript. So, for example, the following is a valid JS script:
I am still working on the representation of proxy record values in JS, which to my mind is the single biggest open question. Curious for folks' feedback on that.
I know there have been security concerns with similar changes folks have proposed in the past. I think this works around most of them - the only objects available in the scope are the normal JavaScript objects available via rhino's "initSafeStandardObjects" function. There won't be any direct access to Java objects from scripts - just the ash global and standard JS class objects, none of which allow access to e.g. the filesystem.
I've attached the patch of my current draft. I've also put it up on my github for easier browsing, but my understanding of standard practice is that discussion stays here. This is a pretty complicated patch. One of the more irritating changes was refactoring the runtime-control aspects of Interpreter into a RuntimeController interface that both Interpreter and the new JavascriptRuntime implement. Happy to take any feedback folks are willing to give on this.
In the current draft, access to the ASH runtime library is available via an "ash" global in JavaScript. So, for example, the following is a valid JS script:
Code:
ash.print("abc" + ash.get_property("banishedMonsters"));
I am still working on the representation of proxy record values in JS, which to my mind is the single biggest open question. Curious for folks' feedback on that.
I know there have been security concerns with similar changes folks have proposed in the past. I think this works around most of them - the only objects available in the scope are the normal JavaScript objects available via rhino's "initSafeStandardObjects" function. There won't be any direct access to Java objects from scripts - just the ash global and standard JS class objects, none of which allow access to e.g. the filesystem.
I've attached the patch of my current draft. I've also put it up on my github for easier browsing, but my understanding of standard practice is that discussion stays here. This is a pretty complicated patch. One of the more irritating changes was refactoring the runtime-control aspects of Interpreter into a RuntimeController interface that both Interpreter and the new JavascriptRuntime implement. Happy to take any feedback folks are willing to give on this.