A core feature of OpenSim, and probably a core feature of any virtual world server, is the ability to program the behavior of in world content. Without programmable content you would have a static world where nothing ever happens no matter what you do. That would get very boring very quickly.
In fact programmability is so important to OpenSim that there are at least five distinct ways to do it: DotNetEngine, XEngine, MRM Scripts, MRM Loader, and Region Modules. Since I just added MRM Loader as a new project in the OpenSim forge, I thought I would explain how I think each of these relate to each other and why OpenSim probably needs at least four of the five.
This Venn diagram captures some of the key aspects of each option:
First, you'll note that I put DotNetEngine and XEgine together. They are both focused on implementing scripting in a way that is compatible with the Linden Scripting Language (LSL) used by SecondLife. I don't understand why there are two engines with such similar functionality. Nor is it clear to me which one is better for any particular scenario. There is some history to this issue. (I don't want to restart endless debate, but does OpenSim really need both of these?)
In any case, LSL compatible scripting is important in that they allow scripts and knowledge to be directly ported from SecondLife into OpenSim. That helps increase OpenSim adoption.
However, both DotNetEngine and XEngine suffer from their LSL roots. LSL wasn't terribly well thought out, the APIs don't follow any conventions consistently, and it bears little resemblance to any widely used programming language or environment.
That is where MRM Scripts come in. MRM (which stands for Mini Region Module) makes no attempt to be compatible with LSL. It provides a well designed object based API and attempts to move beyond LSL's limitations in other ways.
The LSL based engines and MRM script are all focused on "in world" scripting. This is great for simple things, novice content creators, and quick tests or experiments, for example.
But the scripting approach has its limitations. First, you typically edit the script code using the feature poor editor built into the client or you repeatedly cut and paste between editors. Second, you have no ability to organize your code into independent reusable components. And third, you can't debug your code. All of these combine together to make developing complex functionality very frustrating, especially for experienced developers.
MRM Loader takes the same API as MRM Scripts, but makes it available in a professional programming environment. You get to use your favorite CLR language in your favorite editor so you can use features like API auto complete, code navigation, and refractoring support. You build your code into a standard CLR assembly, and you can reference other assemblies as necessary. Finally, you can step through your code using your standard debugger.
Region modules, like MRM Loader, give you a professional programming environment. Unlike MRM, they also give you full access to all of OpenSim's internals (in fact most of OpenSim is implemented using region modules). This makes them extremely powerful but also more complex. Region modules are also more likely to break as OpenSim's implemention evolves, while the MRM API is expected to be more stable. In the end, region modules are well suited for extending OpenSim itself but not well suited for adding behavior to virtual world content.
So we have the following reasons for being:
- DotNetEngine or XEngine - LSL based compatibility
- MRM Script - "modern" in world scripting
- MRM Loader - professional content development
- Region Module - extending OpenSim
Each has a place in the OpenSim programmability picture. MRM Loader isn't intended to replace any of these, but to round out OpenSim's programmability story in a way that will appeal to the professional content creator. I'll go into more detail on how I expect MRM Loader accomplish this in a future post.
