I have been doing some thinking on the ScriptEngine. Actually a whole lot of thinking, and planning. Lots of alien squid-like drawings in my notebook.
Trying to run through the process: Idea, required elements, architecture and finally simplification.
The idea is simply: Moving ScriptEngine to a separate daemon, independent from the region.
This has several big advantages and of course some drawbacks.
- Script does not need to be moved between regions when object it is inside does.
- Scripts can run on separate servers and even clusters of servers, offloading the main region server.
- Script source (and binary) can be secured by running it from a trusted server. Even makes it possible with script rental. You can run your own ScriptEngine.
- We can add the option to move script between regions as usual to avoid network lag on time-critical scripts.
- It is easier to write alternative ScriptEngines, developers are not restricted to .Net.
- ScriptEngines can be more complex and allow bigger and more complex scripts than the region would by default.
- Regions can be more secure as they do not have to execute scripts locally.
- Each region may have to speak to many different scriptengines.
- Network latency will affect script performance.
- Script reliability is much lower.
- Various problems related to authentication.
Of course all the work done with implementing LSL commands so far will survive. That is independent of this rewrite.
I’ll be back with more as it unfolds.
3 thoughts on “Major rewrite number 2”
I believe that those advantages far outweigh the disadvantages. People dont complain about network latency when their mysql server is on a different machine. In the long run, I think it’s better to have as much as we can running as separate daemons, one program, one purpose.
Tedd: thumbs up – great stuff! But still there would be an option to run it as a single binary with the rest of the kitchen (for a click-and-run config) ?
I’d been pondering the same sort of thing, although for a slightly different reason: it would be one less reason not to make region sizes/allocation more dynamic.