[sldev] Scripting the client

[Matt Kimmel]

If we're already thinking forward to a day when the client runs a Mono
VM, it seems to me like it might be worth setting that as a goal now,
rather than going through the pain of integrating traditional Python and
later replacing it with Mono/IronPython.  In my mind, Mono has a number
of advantages as a scripting solution, chief among them being the fact
that it provides a very well-sandboxed execution environment, a trust
and security model (from the Silverlight port), and that, with a bit of
extra effort, we could probably support many different CIL-compilable
languages.  Imagine being able to script the client in your choice of
IronPython, C#, the upcoming CIL-compiled Ruby, and so forth...

-Matt

Dzonatas wrote:
> Lawson English wrote:
>> You said  on the forums that you were working on a Python plug-in. Why
>> specifically Python, rather than Lua, given the relative simplicity of
>> implementing Lua as a plug-in scripting language (that is what it is
>> designed for) compared to implementing a Python plug-in, and the fact
>> that Lua is already used as the scripting language for the Worlds of
>> Warcraft client and has a proven track record for scripting such a
>> system?
>>
>> Please keep in mind that I use neither language. My question is purely
>> a technical one about the relative simplicity and cleanliness of the
>> plug-in.
>>
> 
> Several reasons exist to answer your question.
> 
> There was a notice somewhere posted awhile back that LL has internally
> accepted python as the main scripting language for development. That was
> mainly in the build and maintenance process and didn't reflect LSL. The
> action set a due weight on python to integrate it with the viewer,
> furthermore.
> 
> The sources reveal that some work has already been done to integrate
> python. Since it appeared the integration appeared to be stale, I took
> the initiative to continue that progress from what I noticed has been
> already done.
> 
> Any implementation at such lower-level, be it included in the main exe
> or as a binary plug-in, has to have license compatibility with LL's
> terms. The implementation of python that is already done does carry an
> already accepted license.
> 
> There is some integration between Maya scripts and python, and that is a
> benefit to artist and sculptie creators.
> 
> There is already a well established interface between Blender and
> python, and that is a powerful tool to many artists.
> 
> There is already ample work (Iron Python) to integrate python compiled
> scripts with mono/ecma, which we known mono is already another preferred
> scripting basis. This hints that it is probably easy to move from the
> license model now established to one that also includes mono/ecma basis
> in the viewer, if desired.
> 
> Another item to consider is cost. While I'm not against many other
> languages, they may be more costly to support. Since python has rooted a
> precedence in use, it appears less costly to continue with such route
> than to completely switch to a new scripting language.
> 
> If you want to continue with Lua, I suggest to creat a jira task and
> gather votes. From there, we can create sub-tasks to cover the other
> details needed to implement and support another scripting language 
> under the open source model.
> 
> Others have expressed desire for their choice in scripting languages,
> too. That means the binary plug-in API needs to evolve to allow such
> robustness.
>