[sldev] Re: Feature freeze

[Jim Purbrick (Babbage)]

> I can see the appeal of the idea, but that doesn't seem feasible for 
> this project. Consider some of the long-term branches now reaching 
> completion. Would we just shelf LSL refactoring until everyone is 
> happy, then resume? That is to say, should studio blighty spend the 
> next quarter hunting bugs in the soon-to-be obsolete LSL runtime? 
> (That is also to say, would you be the one who would tell Babbage and 
> Scouse? I know Scouse could take me on by himself, I'm not gonna tell 
> him that.)
In fact, this isn't an either or choice. Arguably the biggest benefit of 
Mono is that it gets us a more stable, tested and secure VM. For example 
SEC-53  is a simulator crash bug on the LSL runtime, but it causes an 
exception to be thrown in the Mono runtime, and is caught at compile 
time by the Mono bytecode verifier. At the moment we're trying to 
implement post hoc verification of LSL bytecode to fix these problems, 
but it's finger in the dyke work and it's extremely unlikely that LSL 
bytecode is completely verifiable. The CIL bytecode that runs on Mono is 
verifiable by design. ECMA-335 describes the algorithm and the 
requirements for each opcode. The Mono bytecode verifier is in active 
development and will be heavily used by Moonlight to run untrusted CIL 
in browsers.

Mono may look like a shiny new feature, but it's arguably a better route 
to stability and security than freezing LSL and fixing bugs in the 
existing runtime.

Cheers,

Jim