[sldev] Script compiler - was: Re: Refactoring and development economy

[Lawson English]

Jim Purbrick (Babbage) wrote:
> The plan is to move to server side compilation in the short term so 
> that we can be sure that LSL bytecode we are executing is the output 
> of the LSL compiler and not just arbitrary bytes or carefully crafted 
> LSO files designed to exploit some weakness in the LSL runtime.
>
> The LSL compiler used by the asset upload framework is exactly the 
> same code that is used in the current viewer compiler, so we can 
> accept patches, but personally I would far rather see us move to allow 
> other .NET languages than spend time patching and extending LSL.
>
> In the long term I'd like to be able to accept arbitrary CLI 
> assemblies that we can verify and trust to run in the server sandbox. 
> This requires significant hardening of the simulator script sandbox 
> and we'd have to put a lot of faith in Mono's nascent verifier, but I 
> think it's a compelling endgame: use any language that targets the CLI 
> to script SL along with the tools and debugging facilities you get 
> with that language. Or invent your own. and call it LSL3 if you must ;-)

As an interim solution to speed up the migration to other languages, say 
, C#, I suggest creating an "LSL3" option which is really a subset of C# 
that is similar to the functionality (and appearance) of LSL2 and start 
cautiously adding "safe" features to it, such as the ability to use 
switch(integer) statements and perhaps others, as found in 
http://wiki.secondlife.com/wiki/LSL3 or 
https://jira.secondlife.com/browse/SVC-1657 . 

This would (could?) allow you to add at least a few new features (really 
unlock more C# syntax) without waiting for a more reliable script 
sandbox and Mono verifier.

At the same time, work could start on more rational versions of the 
current LSL functions that fix all the broken bits, such as child 
rotations that don't work right. Also, a new syntax could be devised and 
tested for the functions that lists of parameters, such as the 
llSetPrimitiveParameters and llGetPrimitiveParameters that isn't 
backwards compatible with LSL2 but is easier to use in a mono compiler 
world.


Lawson