[sldev] Scripting the client

[Lawson English]

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.
>
I doubt that Lua's is any less acceptable.


> There is some integration between Maya scripts and python, and that is 
> a benefit to artist and sculptie creators.
>
/shrug. Not all Maya developers appreciate Python.


> 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.
>
Ironpython is, by its nature, slower than native  python, or any almost 
other native scripting system, for that matter.


> 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.
>
Perhaps. Lua was designed to be a lightweight scripting add-on, and is 
claimed to be faster at most executable tasks than almost any other 
scripting language out there. What is the cost of maintaining Python vs 
maintaining Lua? How does someone determine that? Were these questions 
ever asked when deciding to implement Python as the first scripting 
language for the SL client?



> 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.
>
I'm even more concerned about what is expected to be accessible via such 
an API.

The Worlds of Warcraft client API  exposes virtually everything. Is  
this the plan for scripting in the SL client? Will anything more than 
control of GUI widgets be offered? What  guidelines are used to decide 
what should or should not be scriptable?

My REAL concern is that there appears to have been no real public 
discussion of these issues, let alone any public discussion of what 
design of the client-architecture might make sense in the long-term and 
how scripting and plug-ins should be implemented, both now and under 
some future (hopefully better) architecture.

Will implementing client-scripting under the current architecture of the 
client make it difficult or even impossible to change the design of the 
client to something better?

Etc.