Thread: Discussion: Wonderland scripting architecture#

This page is me experimenting with formatting imported forum content. Maggie Leber

Replies: 11 - Last Post: Dec 23, 2009 11:09 AM by: morrisford

maggiel Posts: 183 Discussion: Wonderland scripting architecture #

Posted: Dec 8, 2009 7:12 AM #

I've spent some time over the last few days looking at the code for morrisford's ScriptingComponent, and thinking about what architectural issues we should be grappling with going forward.

Naturally my own point-of-view is colored by having been active in SecondLife for over two years. And it's clear to me that Morris has been heads-down focused on the use cases he's decided to tackle first. I'm delighted he's taking the lead on understanding the playing field, grappling with things-as-they-are, and he's done some great stuff so far.

But I think this would be a good time (yes, I know there's a 0.5 release coming soon, but there's no time like the present) for a general discussion among the stakeholders about some high-level issues relating to scripting in Wonderland.


-- What functionality do we want to expose to scripting? What's the best way to accomplish that, given that something as relatively primitive (to a SL veteran) as text chat is packaged as a pluggable module? How can we provide discoverable functions to a scripting interface, and have them be relatively easy-to-use given the abundance of diverse scripting languages available under JSR-223?

and closely related: -What events should scripts trigger on? What events should they be able to listen for?

-Where should scripts execute? Solely on the client (as they do in today's ScriptingComponent)? On the Darkstar server? Possibly both places? Should client scripts be able to fire events on server scripts, and vice versa?

-What objects should scripts be attachable to? Any Cell? Avatar Cells? (Morris already has some NPC scripting going on). In SL the only way to script an avatar is to have the Avatar "wear" (attach) a scripted object. That's ugly.

Anyway...I thought I'd put these questions out there, and see what thoughts there are out in the community. I think it would be valuable to have diverse thoughts on these subjects from the Sun devs and the community at-large to provide some focus before design or coding efforts went much further down the road. Some thoughtful architecture work could save an *awful* lot of chaos and wasted effort in future, and give us a richer and higher-quality work product. -maggiel

maggiel Posts: 183 Re: Discussion: Wonderland scripting architecture Posted: Dec 8, 2009 10:20 AM in response to: maggiel #

One other should script source be stored? How should a user change it?

kaplanj Posts: 740 Re: Discussion: Wonderland scripting architecture Posted: Dec 8, 2009 1:18 PM in response to: maggiel #

I think this is a great discussion to have! And some good thoughts to start with. Here is my perspective:

> What functionality do we want to expose to scripting?

The Java scripting APIs actually make it easy to expose almost everything to scripting. I don't necessarily consider this a good thing, as it tends to turn all scripts -- no matter what language they are written in -- into something that looks like Java code. So to me the question is more about how we expose functions in a language-appropriate way to make scripting in that particular language most productive.

> What's the best way to accomplish that, given that something as relatively primitive (to a > SL veteran) as text chat is packaged as a pluggable module? How can we provide > discoverable functions to a scripting interface, and have them be relatively easy-to-use given > the abundance of diverse scripting languages available under JSR-223?

I think scripting should work a lot like the rest of Wonderland: a small core for doing the most basic things, like finding the position of a cell, and then extensibility through components. I imagine that each component would expose a scripting interface, so that when I add the audio component to a cell, for example, my script has access to commands to start and stop audio treatments.

I have been talking to Douglas (of this blog post: about how to do this using Groovy expando objects. This seems like a great solution, but is of course Groovy-specific. My question then is whether components need to expose different scripting interfaces for different scripting languages, or whether they can expose a single Java API that could be used as if native in the various languages.

> Where should scripts execute?

I think for anything beyond simple scripting, the answer will have to be that scripts can run both on the client and the server. Specifically, I imagine the script will want to run wherever the events that trigger it will be generated.

For example, a script that reacts to mouse clicks should run separately on each client. When the user clicks the mouse, the script can react by changing the global state of an object that is seen by all clients.

On the other hand, a script that reacts to global events, like avatars crossing a finish line, will need to run on the server. Given the server's limited view of the world, it will be interesting to see how server-side scripts look.

As an aside, the SharedStateComponent is designed specifically to support scripting by providing a global state that can be changed by any client or the server. It also contains an event mechanism to allow triggering from the client to the server and vice-versa.

> What objects should scripts be attachable to?

I think having scripting as a component that can be attached to any cell makes sense. Avatars are obviously a bit of a special case, so it would be useful to enumerate some use cases for avatar (as opposed to NPC) attached scripts.

> Where should scripts be stored?

Like other assets associated with a cell (artwork, audio), I imagine the scripts will be stored in the webdav repository. The script component would simply contain a list of URLs for associated scripts. The complexity here is with updating and duplicating scripts -- it seems like there will have to be some management if the same script is attached to multiple objects.

morrisford Posts: 1,130 Re: Discussion: Wonderland scripting architecture osted: Dec 8, 2009 1:42 PM in response to: kaplanj #

Good thoughts. Just a little input to add to the discussion.

I very much like the idea of core scripting functions with component based extensibility. This is sorta what I have done so far but started getting messy because there is no standardized API into components. Too many of the current components are oriented toward mouse/key operation with a messy programming interface. This will need to be rectified with a consistent programming interface.

I am already working on server side scripting out of the cellMO. I was told there are no events to be had at this point so I created a messaging based 'event' structure to drive the server side scripting based on client side actions. Also, I haven't figured out where to put server side scripts. I am looking for a server side webdav interface but I haven't found one yet. I also am looking at passing the script with the message from the client but that doesn't look like a very good idea. The use case that I have seen is an interface to a server (or server cluster) based database for storing information to be used by a number of servers/clients working as a 'super system'. I will be using that as a test case for creating a server based mysql database.

The current scripting already has a mechanism for dealing with duplicated/shared scripts stored in webdav that works well.


maggiel Posts: 183 Re: Discussion: Wonderland scripting architecture Posted: Dec 22, 2009 3:59 PM in response to: morrisford Reply

  • bumps mic* This thing on?

Wow, it works!

Message was edited by: maggiel

jslott Posts: 1,133 Re: Discussion: Wonderland scripting architecture Posted: Dec 22, 2009 4:16 PM in response to: maggiel Reply

Yeah seems so...

nicoley Posts: 262 Re: Discussion: Wonderland scripting architecture Posted: Dec 22, 2009 7:59 PM in response to: jslott Reply

Testing: replying to an existing message.


maggiel Posts: 183 Re: Discussion: Wonderland scripting architecture Posted: Dec 22, 2009 4:50 PM in response to: kaplanj Reply

I had originally replied to this before The Big Crash...let me see if I can remember what I said...

"Looking like Java" isn't necessarily a bad thing, as there are other reasons to use a scripting language besides "code looking different". As for Groovy Expando objects, at first reading that looks like the kind "duck typing" Beanshell is good at too.

dougfinn Posts: 22 Re: Discussion: Wonderland scripting architecture Posted: Dec 23, 2009 1:53 AM in response to: maggiel Reply

{Takes out saved forum reply, a few days old, hopes isn't too smelly ...}


As Jon mentioned, I've spent some time developing a scripting component using Groovy. Scripting is added to a cell by right clicking and adding it as a capabilty, then right clicking and popping up a script window via the context menu.

Current features include: interactive scriptwriting with full Groovy functionality; syntax highlighting and editing features via jsyntaxpane; attaching of methods to events; auto imports, similar to Netbeans and Eclipse; open, create, save and compile scripts, which are saved on the server via Webdav; script analysis at the abstract syntax tree level, to get info about classes, methods, variables etc. defined in a script.

The GroovyComponent can do things like attach a script to a cell, eg. write a mousedown behaviour which changes the colour of an object when the mouse button is clicked.

Currently, scripts just execute on the client. I'm trying to use Jon's SharedState component to propogate changes to the server, but have hit a few problems, which I'm working on.

And as Maggie mentions, there's also the architectural consideration - basically, how to update all clients of changes made by a script. Does the script behaviour get sent to the server and executed there, or is it executed locally, with all changes propogated to the server from the client? How would the SharedState component fit into this?

Executing only on the client is a real limitation just now, though it does speed development up a lot - for example, since I didn't know exactly how to change the colour of an object, rather than write Java code and redeploy a "change colour" module with every code change, I could just test code out in the script window until I got it right.

It's great that people are starting to ask questions about this now. And much appreciation to Morris for his ScriptingComponent, which is a groundbreaker!

Perhaps we can get a good discussion going here?

Cheers Douglas

morrisford Posts: 1,130 Re: Discussion: Wonderland scripting architecture Posted: Dec 23, 2009 5:51 AM in response to: dougfinn Reply

In order to help with the discussion of scripting architecture going I wanted to put down a lot of the architecture stuff I did as the scripting component was put together. But first some comments about this forum:

I think this discussion should go on elsewhere with pointers to that discussion in the forum. The forum has been too flaky to depend on for months now with repeated losses of postings and threads. I don't know where it should be but it should be more or less an isolated thread so that the information developed won't get lost in a maze of other threads. I would love to see a WL site for doing all this stuff.


The scripting component was constructed to:

Use client side scripting to reduce reliance on server compute power and bandwidth requirements. Utilize the JSR-223 java scripting interface to allow scripting in a large variety of languages with no language as the 'best' one. Have lowest common denominator support, ie, all scripting languages can perform all functions. Have an event-driven structure. Have the scripts stored on the server side. Have a structure where scripts are stored based on a cell specific value. Have the capability to use the same scripts for multiple cells without copying scripts. Allow for varying script languages for the same cell. Allow the compile and storage of scripts if script language allows compile. Allow scripts that don't have compile capability to run anyway. Have a start up script capability for initial configuration. Have cell based state variables for script usage. Have an inter-cell messaging structure that carries fully definable messages. Allow inter-cell messages to propagate across the server to other clients if desired. Have a communications mechanism that allows for connections from clients to other services outside WL. Have support for basic transforms built in, ie, translate, rotate and scale. Allow for propagation of basic transforms across server if desired. Have support for proximity setting and sensing. Have support for presence setting and sensing. No core WL modifications. Have a mechanism where commands inside cells can be executed from scripts and in a generic fashion. Have server side scripting(FUTURE) Have the same capabilities in terms of communications from server scripts(FUTURE) Have extensive scene graph modification/manipulation support(FUTURE - possibly component or core mods)

I am sure I have missed some original design concepts so I'll add to the list as I think of additional stuff.

Everything in the list exists now except for the last 3 that are marked as FUTURE.

I am really glad that there is finally enough interest in scripting to allow this discussion to occur and I look forward to the continuing discussion.


maggiel Posts: 183 Re: Discussion: Wonderland scripting architecture Posted: Dec 23, 2009 6:30 AM in response to: morrisford Reply

Morris, I share your frustration with the latest outage. But I'd like to continue the scripting architecture discussion here in this thread and not fragment it until we have a better place to host it. As creaky as this forum is, it has the unique quality of being findable and having a critical mass of interested folks on it.

I'd be tickled to have it on a Google Wave, and I have a pile of Wave invites available. I think the problem is that not everybody's ready to make that leap as yet.

Failing that we could open a Google Group. And in the event of a total collapse of the Sun-provided project infrastructure, which is something I think we're all afraid of -- so much so as to be reluctant to mention it -- I could easily see moving to a Sourceforge or Google Code project base. Assuming somebody with suffficient access is lifting backup images of everything off of, hint.

I'm going to plug the SecondLife group for Project Wonderland Interest one more time:

morrisford Posts: 1,130 Re: Discussion: Wonderland scripting architecture Posted: Dec 23, 2009 11:09 AM in response to: maggiel Reply

I visited the SL WL spot. I found a place that has better network support so I could get SL to run.

My big issue with this forum is not just the last week of outage but the last several months of outages. I have seen a lot of stuff disappear. I had been using url references from posts to find things and using info from posts to work on the scripting code and I can't find any of it now. In terms of searching on the forums, good news is that you can search, bad news is that you have to search. I would much rather have a group of living documents that can be easily backed up even if the interface isn't real spiff.

I also have a big issue about that we should be using WL to do the things it was intended for, like collaboration.

Also, a collapse of Sun infrastructure could be nothing more than the Oracle takeover, then the whole could be gone.

Back to Thread List

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-29) was last changed on 30-Nov-2011 18:25 by Josmas Flores