Currently there's a one-to-one mapping between a scripting language and a script runner. The container-hosted and process-forked script runners may support multiple languages, since the execution context provides the actual language and dialect but launching a script in the execution context is the same action regardless of that. In fact, the idea of a "language" should be expanded to execution context or something like that. Execution context can be thought of as similar to a Python virtualenv, where the language version, installed packages, etc., varies but how the script is launched remains the same.

The remote execution context feature requires changes to this functionality:

• Launching process-forked executions is one script runner, while launching container-hosted executions is another
• The "supported languages" will actually be predicated on the known support for each environment. Currently there's a one-to-one relationship between a script language as displayed in the script editor and the supporting script runner. This needs to change so that a script runner can support multiple languages: the container-hosted runner may support pyxnat, bash, R, matlab, bash with FSL, Slicer, etc.
• Additionally script execution contexts should specify access and security levels to restrict access to dangerous or critical environments.