in VR

The Scripting Situation

From Vircadia: link to original post

Written by Dale Glass

Jan 6, 2021

On the previous blog entry the subject of scripting was brought up. I was going to answer there, but the matter is complicated enough to merit an entry on its own. First, a bit of background.

Qt and QtScript

We’re using a library called Qt. Qt covers pretty much everything — cross-platform GUI, networking, multimedia, graphics, concurrency, web surfaces… it’s a huge and very useful library. Currently we’re still using Qt 5.12 for the most part, and are making good progress towards upgrading to the latest we can use, Qt 5.15.2. For scripting we’re using a part of it called QtScript.

The trouble with QtScript is that it was deprecated starting in Qt 5, and is no longer being developed. Qt 6 just came out, and QtScript is no longer a part of it. This is a problem, because at this point Qt 5 is done, and won’t be worked on anymore. There’s not a huge rush with upgrading to the next version yet, as Qt is a big, extremely widely used library, and so we can expect that Qt 5 will remain in wide use for years to come. Still, we’ll need to move on eventually.

Now the question is: what to do about it?

What’s next?

I don’t really know yet. We’ve looked into the matter, and there are various options available, but nothing is set in stone yet and to my knowledge nobody has started work on anything. Roughly, the options available seem to be:

  • Just stay on Qt 5 for now. It’s a viable option for the time being, but not forever. The longer we stay on a deprecated engine, the more things people make that use it, which will make migrating to anything else harder as time passes.
  • QJSEngine, which is the new engine Qt offers to replace QtScript. It has a different API, so it’ll need work.
  • V8, the engine used by Chrome. Going by Qt’s blog posts, V8 was considered by Qt and found to be lacking for their particular needs, particularly making it hard to interface with Qt with good performance.
  • Other scripting languages. Lua, Python, etc. This would involve rewriting everything, though.
  • Support multiple backends, so that you can have both JS and Lua running at once. This may make sense from the point of view of maintaining a flexible architecture, and not being bound by any particular system in the future. But it’ll be more development work, need more documentation, and having multiple scripting languages in use may not be very user friendly.

So far I think multiple backends are likely to happen, if only to allow us to experiment with a new JS engine while the old one is kept as-is to avoid breaking everything. And QJSEngine seems the least difficult path forward, assuming it works well enough.

Other considerations

If we’re going to change the scripting engine, there’s other work that may make sense to undertake at the same time:

  • Remove the functions currently marked as deprecated.
  • See if the current API exports too much in any instances, and deprecate those too.
  • Do a security audit to make sure there’s no way to do anything malicious.
  • Consider new safety mechanisms — access levels, throttling of slow calls, require asking for permission, etc.

My plans

While currently I’m busy with other things, I think I’ve made good progress on getting the smaller but necessary tasks out of the way, and soon I should have time for bigger projects. I have a whole lot of unused vacation time currently, so that could be a good time to at least start trying to do something about this, if nobody else gets there first.

In conclusion

Exciting times are coming! Whatever ends up happening will definitely be a big project.