[sldev] Scripting the client

[Lawson English]

Argent Stonecutter wrote:
> Lawson English:
>> Is there a design team or thread for how to add scripting to the client,
>> ala Lua and/or Python and/or Perl etc?
>>
>> What should be scriptable by such an interface? How it should
>> accomidate/facilitate plug-ins?
>>
>> And so on and so on and so forth?
>>
>> *Etcetera, etcetera, etcetera... --spoken with best royal Yul Brynner
>> accent
>
> There's several different things that people might be looking for in 
> scripting the client, and they probably don't have the same solution.
>
> 1. More control over the client from LSL, this includes things like 
> HTML notecards, improved dialogs (including notecard-driven HTML 
> dialogs, my favorite), as well as communication between LSL and local 
> executing programs and pushing scripts into the client from LSL.
>
> 2. More control over the client from local software, plugins, and so on.
>
> 3. Extending the user interface with scripted extensions to the XML 
> user interface, similar to Firefox extensions, Konfabulator or 
> Dashboard widgets, and so on.
>
> I think that the first section should be severely limited in scope, 
> for security reasons, and a separate extension from the other two. The 
> same language and interpreter could be used (and there's already a 
> Javascript interpreter in the client from Gecko), but there should be 
> a separate instance of it that doesn't have access to any extensions 
> available to locally installed software. Best would be to make it 
> something like "Safe Tcl", where the symbol table available to the 
> untrusted interpreter doesn't even provide entry points for any 
> routine that isn't either fully internal (like math functions) or 
> restricted to only allow safe operations.
>

The ultimate scripted client would be something like the WoW solution.  
That's the main reason I would say to use Lua: it's quick and easy to do 
and we know it works, at least at this level. Any scripting language, 
including one based o mono, would do just as well, of course:

http://www.wowwiki.com/World_of_Warcraft_API

The level of GUI control you're looking for should approach (or exceed) 
this:

http://www.wowwiki.com/Widget_API


Security issues exist in all aspects of this thing. HUDs should be able 
to use existing GUI widgits, but only as graphical devices that send I/O 
back to the world via LSL, not as things that can interact directly with 
the client API.

My solution to import/export chat and IM in and out of Croquet is trival 
on its face (someone from IBM wrote an external language interpreter for 
the client and I'm copying their solultion) but if you let just *any* 
application have access to IM via a plug-in, you run the risk of 
rebroadcasting private IM on an open channel.  I may have to get around 
this in Croquet by not letting external chat/IM enter the Croquet world 
at all, since the normal model is to broadcast a copy of ALL objects to 
every participant in a Croquet world.

I'm a nice guy and don't want IMs to get passed around, but exposing 
chat/IM to inport/export would allow  trivial plugins to be written to 
do exactly what private IM is supposed to prevent.

It would also allow REAL translation solutions, far better than Babbler. 
So should it be included in the plug-in API or not?