code download workaround

I mentioned this on another thread - expanding the concept here:

Perhaps rather than mess with code download or such, we should simply embed javascript, so you could do something like:

luavariable = execjs('some javascript code')

We could then call out to javascript for anything needed - specifically, in my case, socket IO, although access to other unsupported APIs or things like persistent web storage would be options as well. I’m not 100% sure how to deal with callbacks and such, but you get the idea.

Point being - the whole “code download” thing could be an end-user bit of code that isn’t part of Codea, and doesn’t come with it. End-user gets Codea, installs via cut-and-paste their own ‘downloader’ app - and never has to deal with it again. Codea projects would need local file access to other Codea projects, but nothing outside of the Codea Documents directory, and I think maybe we kinda want that anyway for library support.

Just thinking out loud…

execjs() sounds intriguing. I know Apple is more lax on remotely executed Javascript because it goes through their own interpreter. It does mix languages though, and I imagine editing a large string of Javascript inside a Lua function on an iPad would be extremely unpleasant, given it’s already unpleasant to do that in a desktop code editor.

We have made Lua’s loadstring() available post-1.1.2. This is the same as your proposed method except for Lua code.

I agree - I use Codify/Codea in large part because I don’t want to code in Javascript! (I’ve done it. It’s… not pretty, even today, and coding JS today for mobile safari as the only supported browser is an order of magnitude nicer than normal JS coding…)

Does lua support “here documents”?

But - I’d rather code “low-end” libraries in javascript for use by lua than not have them at all.

And apple seems to have a double-standard - what’s ok in javascript (sockets, for example, or grabbing and executing code from the web) is not ok in other languages. Fine - we can play by those rules, it’s easy enough to wrap that functionality in lua wrappers so that we can expose the functionality without, perhaps, breaking the letter of the law, so to speak.

I’m cross posting but I think the key is preserving a sandbox, as long as apple is convinced that the sandbox is preserved then Codea can do anything JavaScript can. Moving things between sandboxes would be done from the app manually outside of Lua.