User:Tedd Maa/stand-alone script engine
Version 1: 20071014 (14th October 2007) By: Tedd Maa
Intro
In this document I try to argue what I think is the best way to go in script engine implementation.
Blog for my OpenSim script engine development: http://teddmaa.blogspot.com/
Current script support
Implementation
Current script support is in LSL2, a proprietary language with syntax similar to C#. It compiles down to a 16KB byte code that is executed on the server. Execution is done fully within that 16KB file, including stack and heap. This enables servers to easily move script between them during runtime. Because of the 16KB limit scripts can not be very large.
There is no inter process communication (communication between scripts) except public chat channels or HTTP requests to a common HTTP server. One or more scripts are put into objects, and run individually. Execution is known to be slow. Scripts are executed locally on each region where the script is running.
Language
The LSL2 script language consists of about 16 events and 360+ functions. The 16 events are triggers from server or from the script engine. The functions are normal functions like math/string manipulation and world manipulation. LSL2 language also has relatively advanced support for single dimension array list manipulation.
Linden Labs are planning to implement C# support through Mono. By doing this more programmers will be able to make applications, and the language syntax will be more consistent. Execution is also expected to be faster.
Future script support
Multiple server implementations
Decentralized architecture and standardization of communication protocol will spawn many different server implementations and areas of use. Scripts must be able to run on different CPU’s and operating systems. This poses a problem when a script can be moved between regions while it is executing. For that we either need a common byte code that can run on all operating systems. Most likely without JIT (Just In Time) compile to be compatible with the stack position during transfer – or a script parser execution model.
Various use
Currently scripts are used mainly to control objects. Because of their limitation they perform small limited functions, and only a few scripts can said to contain any complexity. In the future I would like to see more advanced scripts.
If the limitations of scripts are removed one could develop highly complex scripts like artificial life, advanced procedural generators, environment controls, and even complex game engines that fully control all the rules of the world.
It would of course be up to the server administrator to limit the script engine and user scripts. But a script engine should not only mean “user scripts”. Server administrators should be able to write their own complex engines that control any element of the world. It should for example be possible to write script engines that create rules like Word of Warcraft, Eve Online, etc. It should even be possible to have a cluster of supercomputers running behind a single script, region or grid. Language support We do not want to limit the language support. People should be able to use any language, for example .Net languages, Java, C/C++ and Perl. Just like CGI scripts for web pages, the language that controls the content should not affect the presentation.
Multitasking between many scripts is a problem that needs to be handled on per script engine basis, at least in the nearest foreseeable future. If a region wants to run 10.000 .Net scripts, it is up to the script engine for .Net to do micro threading on these.
Security
Security in this case is a two way street. Script creators may want to protect intellectual property of your script (source code), encryption algorithms, passwords in code, access to HTTP or SQL servers, etc. Even though code might be using security through obscurity, in some cases it is more than good enough. And server administrators don’t really want foreign code running on their server.
As pointed out earlier in this document crossing region borders with the wide language support we want will be difficult. Even if it was possible it would mean that the server you were crossing into had to support your specific language. This in turn means that every script engine for every language supported needs to be 100% secure. And implementations would probably be “Allow everything then try to remove security holes”. Not something you want running on your server. The whole concept of letting anyone run a script on your server is wrong from a security perspective.
New architecture
Today script execution in SL is implemented into the region where the script exists. I propose adding a separate stand alone script engine to the architecture.
Whenever a script is introduced into a region, the region contacts a script server. The IP of the script engine can be determined either by default script engine for that region, user specific script engine or object/script specific script server. It may be necessary for the script to only exist on the script server and the object to contain a script reference. This way one can sell or rent scripts like virtual pets and still keep the source a secret.
Script commands that require manipulation of the world will be sent from remote script server to the region. Events from world to the object will be sent from the region to the script server. Only one connection is necessary from a region to a specific script server regardless of number of scripts (one connection can serve many scripts).
For communication I propose using a custom binary protocol that contains name of function and a dynamic number of parameters of dynamic type. If a command needs reply it should contain an ID that will be used for reply (async). This way the script server and region server can have a continuous flow of function calls going in both directions.
The basic set of commands supported on the script server should be LSL commands. Not all are required though. Some are better suited to be executed inside the script server. For example timers, mathematical functions, string/list manipulation, etc. But the protocol should not be limited to LSL commands only.
The protocol should have versioning and/or some sort of capability implementation. This way server scripting support can be extended by modules on the region server, and remote script servers can utilize implementation specific functionality on region server.
A permission system for remote scripts should also be implemented so that script servers can for example get God-like access to the region server and therefore control more aspects of the world than a single script could.
OpenSim implementation
Originally script support in OpenSim was implemented to run scripts locally. Support for dynamically loading script engines. The same support will be extended to support stand alone remote servers, and the remote servers will be able to load the same .Net modules as OpenSim can locally.