[sldev] Scripting the client

[Dzonatas]

Lawson English wrote:
> 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?

As for lightweight and speed, there are highly optimized VMs much more 
suited for the job besides these more popular languages. The optimized 
VMs add additional cost as it requires everybody to be follow accord 
with it, and the cost not only reflects the provider but also the consumer.

I don't think there ever was a mandate to implement python as the first 
scripting language. It appears python was a choice of consolidation. 
Someone else with TheOfficialWord(tm) can correct me there. =)

Based on hints of previous documents, that, under the current solid exe 
model, an exposed API is too risky to implement. (I know some who want 
to overlook that risk.) Therefore, binary plug-ins (similar to ABIs) 
have been needed in order to isolate a particular program space away 
from the solid-core exe model. As stated many times on this list, 
however, there is much friction to add any additional DLL, DSO, DYNLIB 
or likewise to be officially distributed along with a Second Life 
installation.

In reality under the hood, think of it more like python is being 
completely exiled from the solid-core exe and put into its own space 
rather than being the first scripting language. This particular effort 
has fallen into the hands of open source developers, which I have take 
an initiative to develop since I already have other works with similar 
binary plug-in needs.


> 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?
The votes tallied in jira issues are helpful to what is immediately needed.

>
> 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.
There has been, but it keeps going stale. Several resources on the wiki, 
here is some:

https://wiki.secondlife.com/wiki/Plugin_architecture_survey
https://wiki.secondlife.com/wiki/SLDev-Traffic_1#C.2B.2B_motivated_Plugin_Bindings
https://wiki.secondlife.com/wiki/Sculpted_Prims:_3d_Software_Guide 
(search for "plugins" on this page)
https://wiki.secondlife.com/wiki/Plugin_architecture_Security
https://wiki.secondlife.com/wiki/Sculptie_Dev
https://wiki.secondlife.com/wiki/Plugin_architecture
https://wiki.secondlife.com/wiki/User_Interface_Roadmap

And, some InternalWord(tm):

Bryan O'Sullivan wrote:
> Lawson English wrote:
>> Is there a design team or thread for how to add scripting to the 
>> client, ala Lua and/or Python and/or Perl etc?
>
> We're in the early stages of kicking this idea around internally.  As 
> you might know, we're going to switch to Mono for LSL scripting on the 
> server side; that's overwhelmingly likely to be the direction we'll 
> take on the viewer side, too, because of its multilingual capabilities. 

 From here I can recommend that any forward direction taken needs a 
proof-of-concept in its path.

-- 
Power to Change the Void