intfiction.org

I want to allow people to attach event handlers. Regexs could restrict code to one namespace, but to do the same to the callback functions seems a tall order. Still, if you think it can be done that would be nice. Specifying a subset of jQuery will take the same work as specifying a bunch of functions in some other namespace (or possibly less).

When this first gets onto iplayif.com, I'll have the user confirm that they want to allow JS. Then once we figure out a way to safely sandbox it while still providing a rich enough environment we could add a new glk function and depreciate the old one.

Also, I'm not sure how it will work for Inform 7 generated web pages. If you play them from file: I think they will have access to all the data from other I7 webpages that you've played locally, so the user confirmation may still be needed.

I've talked about this briefly with Dannii and he has a system that goes a long way towards this. It's definitely technically possible.

_________________
Vorple UI library — Beta testing site — Blog

Also to clarify: this system would be restricted to higher level functions than what has possibly been discussed so far. It wouldn't allow for callbacks and such. I'm thinking more like very complete JS modules that are controlled from the story file, like "grant achievement "treasure found" to the player" as opposed to the story file providing the JS code for the achievement system.

_________________
Vorple UI library — Beta testing site — Blog

That can't possibly be reliable. I am eager to hear about other possibilities. :)



I'm not sure what you mean by this. The whole point is for JS modules to be provided in the Blorb file, not as literal text in the story file. But it's code from the game author either way, so it's equally untrustworthy (from the player's point of view. Or the web app's, if the web app isn't hosted by the game author.)

I read the Short Form only, and just wanted to say - this sounds pretty cool.

I mean that JS modules would not be in the blorb file, but in an external library provided by the interpreter. The game could only call those ready-made blocks, not provide its own modules.

But, I'm looking at this from a certain perspective. As long as there's some way of getting access to JavaScript from the story, I'm happy :)

_________________
Vorple UI library — Beta testing site — Blog

I think the best approach for forward compatibility is to store the JS code in the blorb. That way if future browser incompatibilities make it nonfunctional, someone else could rip the blorb resources, rewrite the JS in a compatible way, and repack the blorb.

I'm not excited about external libraries because then the games are no longer self-contained, and there is a nontrivial version management / change control process that those libraries would have to follow in order to avoid breaking existing games hosted in the same environment.

I have mixed feelings about embedded JS literals. On the one hand I've just finished a quick TADS 3 extension that allows an author to do exactly that, and I must say it's quite liberating to be able to script the entire UI from game logic. On the other hand, there's some concern about forward compatibility this way.

For Vorple/StructIO what I was imagining is more of an RPC system, rather than a scripting environment. When I implement Glk in StructIO I intend to allow direct access to StructIO too, but it will be via passing commands in JSON or YAML. It will be limited to quite basic element manipulation, but will be there for people who want more than Glk's windows, paragraphs and spans.

However with this new plan instead of a Vorple API that we access, there could instead be a Vorple library that could be compiled into the blorb. The paragraph IDs are just longing to be used for error folding. The jQuery subset I've been talking about will again be an API, but as it will be low level compared to Vorple we won't have to update it much, or ever. jQuery is frequently updated, but the core of it has been stable for a very long time.

Or you could stick to an API, either within Glk, or parallel to it. But then it would have tricky version management problems as Ben said. I think Vorple might well have a higher rate of change than Glk. (And the Glk rate of change we see now is higher than it's been in a long time!)

Oh, and I've just realised that we can use Web Workers as a much simpler and faster sandbox. They're quite widely supported now.

And for non-JavaScript interpreters?

I don't understand the omission of this straightforward, standard text formatting feature that's already in HTML/CSS and the Z-machine. IMO, the lack of dynamic styling has always been the weak spot in Glk, and this is the perfect time to fix it. If it's not going to be in the standard, I hope zarf is still willing to reserve a few selector numbers for it, because I plan to personally add it to every open source interpreter I can build.

Proposed subset of the jQuery API that would not be allowed for web Glk. Only basic AJAX stuff allowed, no direct DOM access.
I'm not sure about the ones with a ?

jQuery.ajax
.ajaxComplete
.ajaxError
jQuery.ajaxPrefilter
.ajaxSend
jQuery.ajaxSetup
.ajaxStart
.ajaxStop
.ajaxSuccess
.attr
jQuery.boxModel
jQuery.browser ?
jQuery.Callbacks ?
jQuery.cssHooks
jQuery.fx.interval
jQuery.fx.off
.get
jQuery.getScript
jQuery.globalEval
jQuery.holdReady
.html ?
.load
jQuery.noConflict
.prop
.ready
jQuery.sub
jQuery.support