[sldev] Scripting the client

Dzonatas dzonatas at dzonux.net
Thu Aug 2 07:32:54 PDT 2007


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.

-- 
Power to Change the Void


More information about the SLDev mailing list