[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