Second Life Wiki - User contributions [en]

User talk:Tedd Maa/stand-alone script engine

2007-10-16T19:54:11Z

Tedd Maa:

* Although this is interesting Tedd, it doesn't seem to keep in mind one very fundamental issue: computations at the server end have limited scalability, relative to any of the pressure points on scaling, which all derive from population pressure in one way or another. No matter how we partition computing resources server-side, there will always be a key computational workload there for physics etc, so in general there is only limited power left over for ambitious scripting. While we'd all like high-powered in-world scripting, that's just not going to happen as long as the only available computing horsepower for scripting is server-side.

* Although it's not going to happen for a long time, relatively unlimited scripting power is ultimately going to have to come by harnessing the clients, through server-side orchestration of partitioned tasks distributed very dynamically across all connected participants. This is the '''only''' source of computing power that both scales with population and offers massive resource per leaf node. What's more, with multicore CPUs everywhere (and with very little work for them to do because desktop apps tend not to be structured for parallelism), this is one resource that has a very bright future.

* So, while you offer some interesting things to think about here, if you want to look ahead to a future of high-powered server-side scripting, you really need to think about workload offloading too. (That's still "server-side scripting", even though the computations are distributed and run client-side, because such computations can never under any circumstances affect the client state; "client-side scripting" is a different matter altogether.) --[[User:Morgaine Dinova|Morgaine Dinova]] 04:18, 15 October 2007 (PDT)

----

[[User:Tedd Maa|Tedd Maa]]: In reply to the points by Morgaine.

* There are limitations on the server side, yes. But this does not mean we should purposely design the scripting system in a bad way. It is up to the server itself to scale physics well. But the script engine is not limited to controlling physical objects. It can be clouds, smoke or even gameplay rules that don't even exist as an object in the world.

* The whole point of this design is to be able to run scripts from anywhere. For example from the client. But running it from the client breaks persistency in the world. When user logs off, objects disappear. So I imagine people who want to run their own script engine having a shell somewhere like we did back in the 90's with good old bots and bouncers on IRC. But your script can very well be bound to a script engine embedded in your SL viewer for example, no problem. The region server doesn't need to discriminate on who is running the script server if server admin doesn't want it to.

* It is still ''called'' server-side scripting. But one single script (or multiple scripts) can be any program in any programming language running on any number of computers on any number of different operating systems and CPUs anywhere in the world. As long as the region has only ONE endpoint to speak to it does not discriminate on implementation, operating system, number of computers involved in computation, etc. This is the whole essence of my plan. I will look through the document and see if maybe I didn't communicate that clearly enough. Its still just a first draft.

[[User:Tedd Maa|Tedd Maa]] 20071015 16:40 UTC/GMT+1

== Object Orientated Program Environment ==

Most traditional OOP languages fall short of the object orientated design. That is they call themselves a object-oriented program language, but they are not much of a object orientated approach outside of the language itself. Notice how I use "oriented" and "orientated." One leans towards the paradigm from the outside and the other is centered in the entire paradigm and works outward. At first glance of the your plan I heard a familiar tune, and it matches with the object-oriented program languages. Such languages have been quite a step in the industry, but they have been pushed out to market before their maturity.

As you can see from my post about "[[User:Dzonatas Sol|Client Script & Persistent Data Object]]," one of the ideas here is similar. In fact, the entire concept you have presented so far can be summed up underneath paravirtual machines. On that point, to call this "Tedds stand-alone script engine" may do some injustice to those who might want to contribute to the development of this project.

Another point, the security has to go much deeper than what I see talked about in the article. To offset the execute state to a different physical area is not enough, for example. We need to be able to run arbitrary code in arbitrary locations.

I stay focused on the object-orientated environments, and I hope you follow if you continue such motives to rewrite the engine. [[User:Dzonatas Sol|Dzonatas Sol]] 12:31, 15 October 2007 (PDT)

----

good point on the "Tedds stand-alone script engine" - wasn't meant to name it at all, was meant as "Tedds proposal on ..." or "Tedds discussion on ...". I will fix that in next revision (hopefully coming in a couple of days).

Security is something I'm still thinking about. I'll try to get something more about that into next revision.
(security always comes first, so it will probably dictate some of the details in the design)

[[User:Tedd Maa|Tedd Maa]] 20071016 21:50 UTC/GMT+1

User:Tedd Maa/stand-alone script engine

2007-10-15T19:11:55Z

Tedd Maa:

Version 1: 20071014 (14th October 2007)
By: [[User:Tedd Maa|Tedd Maa]]

=Intro=
In this document I try to argue what I think is the best way to go in script engine implementation.

Blog for my OpenSim script engine development: [http://teddmaa.blogspot.com/ http://teddmaa.blogspot.com/]

=Current script support=
==Implementation==
Current script support is in LSL2, a proprietary language with syntax similar to C#. It compiles down to a 16KB byte code that is executed on the server. Execution is done fully within that 16KB file, including stack and heap. This enables servers to easily move script between them during runtime. Because of the 16KB limit scripts can not be very large.

There is no inter process communication (communication between scripts) except public chat channels or HTTP requests to a common HTTP server. One or more scripts are put into objects, and run individually. Execution is known to be slow. Scripts are executed locally on each region where the script is running.

==Language==
The LSL2 script language consists of about 16 events and 360+ functions. The 16 events are triggers from server or from the script engine. The functions are normal functions like math/string manipulation and world manipulation. LSL2 language also has relatively advanced support for single dimension array list manipulation.

Linden Labs are planning to implement C# support through Mono. By doing this more programmers will be able to make applications, and the language syntax will be more consistent. Execution is also expected to be faster.

=Future script support=
==Multiple server implementations==
Decentralized architecture and standardization of communication protocol will spawn many different server implementations and areas of use. Scripts must be able to run on different CPU’s and operating systems. This poses a problem when a script can be moved between regions while it is executing. For that we either need a common byte code that can run on all operating systems. Most likely without JIT (Just In Time) compile to be compatible with the stack position during transfer – or a script parser execution model.

==Various use==
Currently scripts are used mainly to control objects. Because of their limitation they perform small limited functions, and only a few scripts can said to contain any complexity.
In the future I would like to see more advanced scripts.

If the limitations of scripts are removed one could develop highly complex scripts like artificial life, advanced procedural generators, environment controls, and even complex game engines that fully control all the rules of the world.

It would of course be up to the server administrator to limit the script engine and user scripts. But a script engine should not only mean “user scripts”. Server administrators should be able to write their own complex engines that control any element of the world. It should for example be possible to write script engines that create rules like Word of Warcraft, Eve Online, etc. It should even be possible to have a cluster of supercomputers running behind a single script, region or grid.
Language support
We do not want to limit the language support. People should be able to use any language, for example .Net languages, Java, C/C++ and Perl. Just like CGI scripts for web pages, the language that controls the content should not affect the presentation.

Multitasking between many scripts is a problem that needs to be handled on per script engine basis, at least in the nearest foreseeable future. If a region wants to run 10.000 .Net scripts, it is up to the script engine for .Net to do micro threading on these.

==Security==
Security in this case is a two way street. Script creators may want to protect intellectual property of your script (source code), encryption algorithms, passwords in code, access to HTTP or SQL servers, etc. Even though code might be using security through obscurity, in some cases it is more than good enough. And server administrators don’t really want foreign code running on their server.

As pointed out earlier in this document crossing region borders with the wide language support we want will be difficult. Even if it was possible it would mean that the server you were crossing into had to support your specific language. This in turn means that every script engine for every language supported needs to be 100% secure. And implementations would probably be “Allow everything then try to remove security holes”. Not something you want running on your server. The whole concept of letting anyone run a script on your server is wrong from a security perspective.

==New architecture==
Today script execution in SL is implemented into the region where the script exists. I propose adding a separate stand alone script engine to the architecture.

Whenever a script is introduced into a region, the region contacts a script server. The IP of the script engine can be determined either by default script engine for that region, user specific script engine or object/script specific script server. It may be necessary for the script to only exist on the script server and the object to contain a script reference. This way one can sell or rent scripts like virtual pets and still keep the source a secret.

Script commands that require manipulation of the world will be sent from remote script server to the region. Events from world to the object will be sent from the region to the script server. Only one connection is necessary from a region to a specific script server regardless of number of scripts (one connection can serve many scripts).

For communication I propose using a custom binary protocol that contains name of function and a dynamic number of parameters of dynamic type. If a command needs reply it should contain an ID that will be used for reply (async). This way the script server and region server can have a continuous flow of function calls going in both directions.

The basic set of commands supported on the script server should be LSL commands. Not all are required though. Some are better suited to be executed inside the script server. For example timers, mathematical functions, string/list manipulation, etc. But the protocol should not be limited to LSL commands only.

The protocol should have versioning and/or some sort of capability implementation. This way server scripting support can be extended by modules on the region server, and remote script servers can utilize implementation specific functionality on region server.

A permission system for remote scripts should also be implemented so that script servers can for example get God-like access to the region server and therefore control more aspects of the world than a single script could.

==OpenSim implementation==
Originally script support in OpenSim was implemented to run scripts locally. Support for dynamically loading script engines. The same support will be extended to support stand alone remote servers, and the remote servers will be able to load the same .Net modules as OpenSim can locally.

User:Tedd Maa

2007-10-15T15:52:26Z

Tedd Maa: New page: =About me= My name is Tedd Hansen, my SL cyberego is Tedd Maa. I am 27 years old, live in Oslo, Norway. I run my own little company with programming related project management. I have bee...

=About me=
My name is Tedd Hansen, my SL cyberego is Tedd Maa.

I am 27 years old, live in Oslo, Norway. I run my own little company with programming related project management. I have been programming since forever (age 7 or so).

=OpenSim=
I am working on the OpenSim project ([http://www.opensimulator.org/ http://www.opensimulator.org/]) with main focus on programming the script engine. The OpenSim project is a BSD licensed Second Life server being developed by volunteers around the world.

I have through the OpenSim project been working with script engine implementation for some time. From the initial script engine where I did LSL byte code to .Net CIL (.Net assembly language) converting, compiling and execution, to the current one compiling LSL text scripts to .Net assemblies (.dll).

=Interests=
My interests span from any nerds wet dream of robotics and AI to algorithms. My hobby for the past 15 or so years has been mainly programming, every day. With focus on algorithms suchs as early 3D (like Doom 1 & 2), communication protocols, compression, search, file systems, operative system kernels, etc. I enjoy a good challenge.

=Plans for SL=
Mostly for fun. I believe this technology has the potential and is in the right time and place for it to happen. It just needs a major rewrite. It has a big untapped commercial potential, and I think in the coming years it will position itself in the market in ways we can not imagine now. A few will imagine it in time and make good money from it, most will just follow them. Same old story.

I hope SL will be THE place for artificial life experiments, and that we can all experiment on the same piece land. http://www.alifegrid.com/

User talk:Tedd Maa/stand-alone script engine

2007-10-15T14:39:38Z

Tedd Maa:

User talk:Tedd Maa/stand-alone script engine

2007-10-15T14:34:52Z

Tedd Maa:

User:Tedd Maa/stand-alone script engine

2007-10-15T13:52:44Z

Tedd Maa:

Version 1: 20071014 (14th October 2007)

=Intro=
My name is Tedd Hansen, SL alias Tedd Maa. I am 27 years old, live in Oslo, Norway. I run my own company with programming related project management. I have been programming since forever (age 7 or so).

I am working on the OpenSim project (http://www.opensimulator.org/) with main focus on programming the script engine. The OpenSim project is a BSD licensed Second Life server being developed by volunteers around the world. Many people are contributing.

I have through the OpenSim project been working with script engine implementation for some time. From the initial script engine where I did LSL ByteCode to .Net CIL (.Net assembly language) converting, to the current compiling LSL scripts to .Net assemblies (.dll).

In this document I try to argue what I think is the best way to go in script engine implementation.

Blog for my OpenSim script engine development: [http://teddmaa.blogspot.com/ http://teddmaa.blogspot.com/]

=Current script support=
==Implementation==
Current script support is in LSL2, a proprietary language with syntax similar to C#. It compiles down to a 16KB byte code that is executed on the server. Execution is done fully within that 16KB file, including stack and heap. This enables servers to easily move script between them during runtime. Because of the 16KB limit scripts can not be very large.

There is no inter process communication (communication between scripts) except public chat channels or HTTP requests to a common HTTP server. One or more scripts are put into objects, and run individually. Execution is known to be slow. Scripts are executed locally on each region where the script is running.

==Language==
The LSL2 script language consists of about 16 events and 360+ functions. The 16 events are triggers from server or from the script engine. The functions are normal functions like math/string manipulation and world manipulation. LSL2 language also has relatively advanced support for single dimension array list manipulation.

Linden Labs are planning to implement C# support through Mono. By doing this more programmers will be able to make applications, and the language syntax will be more consistent. Execution is also expected to be faster.

=Future script support=
==Multiple server implementations==
Decentralized architecture and standardization of communication protocol will spawn many different server implementations and areas of use. Scripts must be able to run on different CPU’s and operating systems. This poses a problem when a script can be moved between regions while it is executing. For that we either need a common byte code that can run on all operating systems. Most likely without JIT (Just In Time) compile to be compatible with the stack position during transfer – or a script parser execution model.

==Various use==
Currently scripts are used mainly to control objects. Because of their limitation they perform small limited functions, and only a few scripts can said to contain any complexity.
In the future I would like to see more advanced scripts.

If the limitations of scripts are removed one could develop highly complex scripts like artificial life, advanced procedural generators, environment controls, and even complex game engines that fully control all the rules of the world.

It would of course be up to the server administrator to limit the script engine and user scripts. But a script engine should not only mean “user scripts”. Server administrators should be able to write their own complex engines that control any element of the world. It should for example be possible to write script engines that create rules like Word of Warcraft, Eve Online, etc. It should even be possible to have a cluster of supercomputers running behind a single script, region or grid.
Language support
We do not want to limit the language support. People should be able to use any language, for example .Net languages, Java, C/C++ and Perl. Just like CGI scripts for web pages, the language that controls the content should not affect the presentation.

Multitasking between many scripts is a problem that needs to be handled on per script engine basis, at least in the nearest foreseeable future. If a region wants to run 10.000 .Net scripts, it is up to the script engine for .Net to do micro threading on these.

==Security==
Security in this case is a two way street. Script creators may want to protect intellectual property of your script (source code), encryption algorithms, passwords in code, access to HTTP or SQL servers, etc. Even though code might be using security through obscurity, in some cases it is more than good enough. And server administrators don’t really want foreign code running on their server.

As pointed out earlier in this document crossing region borders with the wide language support we want will be difficult. Even if it was possible it would mean that the server you were crossing into had to support your specific language. This in turn means that every script engine for every language supported needs to be 100% secure. And implementations would probably be “Allow everything then try to remove security holes”. Not something you want running on your server. The whole concept of letting anyone run a script on your server is wrong from a security perspective.

==New architecture==
Today script execution in SL is implemented into the region where the script exists. I propose adding a separate stand alone script engine to the architecture.

Whenever a script is introduced into a region, the region contacts a script server. The IP of the script engine can be determined either by default script engine for that region, user specific script engine or object/script specific script server. It may be necessary for the script to only exist on the script server and the object to contain a script reference. This way one can sell or rent scripts like virtual pets and still keep the source a secret.

Script commands that require manipulation of the world will be sent from remote script server to the region. Events from world to the object will be sent from the region to the script server. Only one connection is necessary from a region to a specific script server regardless of number of scripts (one connection can serve many scripts).

For communication I propose using a custom binary protocol that contains name of function and a dynamic number of parameters of dynamic type. If a command needs reply it should contain an ID that will be used for reply (async). This way the script server and region server can have a continuous flow of function calls going in both directions.

The basic set of commands supported on the script server should be LSL commands. Not all are required though. Some are better suited to be executed inside the script server. For example timers, mathematical functions, string/list manipulation, etc. But the protocol should not be limited to LSL commands only.

The protocol should have versioning and/or some sort of capability implementation. This way server scripting support can be extended by modules on the region server, and remote script servers can utilize implementation specific functionality on region server.

A permission system for remote scripts should also be implemented so that script servers can for example get God-like access to the region server and therefore control more aspects of the world than a single script could.

==OpenSim implementation==
Originally script support in OpenSim was implemented to run scripts locally. Support for dynamically loading script engines. The same support will be extended to support stand alone remote servers, and the remote servers will be able to load the same .Net modules as OpenSim can locally.

User:Tedd Maa/stand-alone script engine

2007-10-14T21:02:21Z

Tedd Maa: /* Intro */

=Intro=
My name is Tedd Hansen, SL alias Tedd Maa. I am 27 years old, live in Oslo, Norway. I run my own company with programming related project management. I have been programming since forever (age 7 or so).

I am working on the OpenSim project (http://www.opensimulator.org/) with main focus on programming the script engine. The OpenSim project is a BSD licensed Second Life server being developed by volunteers around the world. Many people are contributing.

I have through the OpenSim project been working with script engine implementation for some time. From the initial script engine where I did LSL ByteCode to .Net CIL (.Net assembly language) converting, to the current compiling LSL scripts to .Net assemblies (.dll).

In this document I try to argue what I think is the best way to go in script engine implementation.

Blog for my OpenSim script engine development: [http://teddmaa.blogspot.com/ http://teddmaa.blogspot.com/]

=Current script support=
==Implementation==
Current script support is in LSL2, a proprietary language with syntax similar to C#. It compiles down to a 16KB byte code that is executed on the server. Execution is done fully within that 16KB file, including stack and heap. This enables servers to easily move script between them during runtime. Because of the 16KB limit scripts can not be very large.

There is no inter process communication (communication between scripts) except public chat channels or HTTP requests to a common HTTP server. One or more scripts are put into objects, and run individually. Execution is known to be slow. Scripts are executed locally on each region where the script is running.

==Language==
The LSL2 script language consists of about 16 events and 360+ functions. The 16 events are triggers from server or from the script engine. The functions are normal functions like math/string manipulation and world manipulation. LSL2 language also has relatively advanced support for single dimension array list manipulation.

Linden Labs are planning to implement C# support through Mono. By doing this more programmers will be able to make applications, and the language syntax will be more consistent. Execution is also expected to be faster.

=Future script support=
==Multiple server implementations==
Decentralized architecture and standardization of communication protocol will spawn many different server implementations and areas of use. Scripts must be able to run on different CPU’s and operating systems. This poses a problem when a script can be moved between regions while it is executing. For that we either need a common byte code that can run on all operating systems. Most likely without JIT (Just In Time) compile to be compatible with the stack position during transfer – or a script parser execution model.

==Various use==
Currently scripts are used mainly to control objects. Because of their limitation they perform small limited functions, and only a few scripts can said to contain any complexity.
In the future I would like to see more advanced scripts.

If the limitations of scripts are removed one could develop highly complex scripts like artificial life, advanced procedural generators, environment controls, and even complex game engines that fully control all the rules of the world.

It would of course be up to the server administrator to limit the script engine and user scripts. But a script engine should not only mean “user scripts”. Server administrators should be able to write their own complex engines that control any element of the world. It should for example be possible to write script engines that create rules like Word of Warcraft, Eve Online, etc. It should even be possible to have a cluster of supercomputers running behind a single script, region or grid.
Language support
We do not want to limit the language support. People should be able to use any language, for example .Net languages, Java, C/C++ and Perl. Just like CGI scripts for web pages, the language that controls the content should not affect the presentation.

Multitasking between many scripts is a problem that needs to be handled on per script engine basis, at least in the nearest foreseeable future. If a region wants to run 10.000 .Net scripts, it is up to the script engine for .Net to do micro threading on these.

==Security==
Security in this case is a two way street. Script creators may want to protect intellectual property of your script (source code), encryption algorithms, passwords in code, access to HTTP or SQL servers, etc. Even though code might be using security through obscurity, in some cases it is more than good enough. And server administrators don’t really want foreign code running on their server.

As pointed out earlier in this document crossing region borders with the wide language support we want will be difficult. Even if it was possible it would mean that the server you were crossing into had to support your specific language. This in turn means that every script engine for every language supported needs to be 100% secure. And implementations would probably be “Allow everything then try to remove security holes”. Not something you want running on your server. The whole concept of letting anyone run a script on your server is wrong from a security perspective.

==New architecture==
Today script execution in SL is implemented into the region where the script exists. I propose adding a separate stand alone script engine to the architecture.

Whenever a script is introduced into a region, the region contacts a script server. The IP of the script engine can be determined either by default script engine for that region, user specific script engine or object/script specific script server. It may be necessary for the script to only exist on the script server and the object to contain a script reference. This way one can sell or rent scripts like virtual pets and still keep the source a secret.

Script commands that require manipulation of the world will be sent from remote script server to the region. Events from world to the object will be sent from the region to the script server. Only one connection is necessary from a region to a specific script server regardless of number of scripts (one connection can serve many scripts).

For communication I propose using a custom binary protocol that contains name of function and a dynamic number of parameters of dynamic type. If a command needs reply it should contain an ID that will be used for reply (async). This way the script server and region server can have a continuous flow of function calls going in both directions.

The basic set of commands supported on the script server should be LSL commands. Not all are required though. Some are better suited to be executed inside the script server. For example timers, mathematical functions, string/list manipulation, etc. But the protocol should not be limited to LSL commands only.

The protocol should have versioning and/or some sort of capability implementation. This way server scripting support can be extended by modules on the region server, and remote script servers can utilize implementation specific functionality on region server.

A permission system for remote scripts should also be implemented so that script servers can for example get God-like access to the region server and therefore control more aspects of the world than a single script could.

==OpenSim implementation==
Originally script support in OpenSim was implemented to run scripts locally. Support for dynamically loading script engines. The same support will be extended to support stand alone remote servers, and the remote servers will be able to load the same .Net modules as OpenSim can locally.

User:Tedd Maa/stand-alone script engine

2007-10-14T21:02:03Z

Tedd Maa: /* Intro */

=Intro=
My name is Tedd Hansen, SL alias Tedd Maa. I am 27 years old, live in Oslo, Norway. I run my own company with programming related project management. I have been programming since forever (age 7 or so).

I am working on the OpenSim project (http://www.opensimulator.org/) with main focus on programming the script engine. The OpenSim project is a BSD licensed Second Life server being developed by volunteers around the world. Many people are contributing.

I have through the OpenSim project been working with script engine implementation for some time. From the initial script engine where I did LSL ByteCode to .Net CIL (.Net assembly language) converting, to the current compiling LSL scripts to .Net assemblies (.dll).

In this document I try to argue what I think is the best way to go in script engine implementation.

Blog for my OpenSim script engine development: [http://teddmaa.blogspot.com/|http://teddmaa.blogspot.com/]

=Current script support=
==Implementation==
Current script support is in LSL2, a proprietary language with syntax similar to C#. It compiles down to a 16KB byte code that is executed on the server. Execution is done fully within that 16KB file, including stack and heap. This enables servers to easily move script between them during runtime. Because of the 16KB limit scripts can not be very large.

There is no inter process communication (communication between scripts) except public chat channels or HTTP requests to a common HTTP server. One or more scripts are put into objects, and run individually. Execution is known to be slow. Scripts are executed locally on each region where the script is running.

==Language==
The LSL2 script language consists of about 16 events and 360+ functions. The 16 events are triggers from server or from the script engine. The functions are normal functions like math/string manipulation and world manipulation. LSL2 language also has relatively advanced support for single dimension array list manipulation.

Linden Labs are planning to implement C# support through Mono. By doing this more programmers will be able to make applications, and the language syntax will be more consistent. Execution is also expected to be faster.

=Future script support=
==Multiple server implementations==
Decentralized architecture and standardization of communication protocol will spawn many different server implementations and areas of use. Scripts must be able to run on different CPU’s and operating systems. This poses a problem when a script can be moved between regions while it is executing. For that we either need a common byte code that can run on all operating systems. Most likely without JIT (Just In Time) compile to be compatible with the stack position during transfer – or a script parser execution model.

==Various use==
Currently scripts are used mainly to control objects. Because of their limitation they perform small limited functions, and only a few scripts can said to contain any complexity.
In the future I would like to see more advanced scripts.

If the limitations of scripts are removed one could develop highly complex scripts like artificial life, advanced procedural generators, environment controls, and even complex game engines that fully control all the rules of the world.

It would of course be up to the server administrator to limit the script engine and user scripts. But a script engine should not only mean “user scripts”. Server administrators should be able to write their own complex engines that control any element of the world. It should for example be possible to write script engines that create rules like Word of Warcraft, Eve Online, etc. It should even be possible to have a cluster of supercomputers running behind a single script, region or grid.
Language support
We do not want to limit the language support. People should be able to use any language, for example .Net languages, Java, C/C++ and Perl. Just like CGI scripts for web pages, the language that controls the content should not affect the presentation.

Multitasking between many scripts is a problem that needs to be handled on per script engine basis, at least in the nearest foreseeable future. If a region wants to run 10.000 .Net scripts, it is up to the script engine for .Net to do micro threading on these.

==Security==
Security in this case is a two way street. Script creators may want to protect intellectual property of your script (source code), encryption algorithms, passwords in code, access to HTTP or SQL servers, etc. Even though code might be using security through obscurity, in some cases it is more than good enough. And server administrators don’t really want foreign code running on their server.

As pointed out earlier in this document crossing region borders with the wide language support we want will be difficult. Even if it was possible it would mean that the server you were crossing into had to support your specific language. This in turn means that every script engine for every language supported needs to be 100% secure. And implementations would probably be “Allow everything then try to remove security holes”. Not something you want running on your server. The whole concept of letting anyone run a script on your server is wrong from a security perspective.

==New architecture==
Today script execution in SL is implemented into the region where the script exists. I propose adding a separate stand alone script engine to the architecture.

Whenever a script is introduced into a region, the region contacts a script server. The IP of the script engine can be determined either by default script engine for that region, user specific script engine or object/script specific script server. It may be necessary for the script to only exist on the script server and the object to contain a script reference. This way one can sell or rent scripts like virtual pets and still keep the source a secret.

Script commands that require manipulation of the world will be sent from remote script server to the region. Events from world to the object will be sent from the region to the script server. Only one connection is necessary from a region to a specific script server regardless of number of scripts (one connection can serve many scripts).

For communication I propose using a custom binary protocol that contains name of function and a dynamic number of parameters of dynamic type. If a command needs reply it should contain an ID that will be used for reply (async). This way the script server and region server can have a continuous flow of function calls going in both directions.

The basic set of commands supported on the script server should be LSL commands. Not all are required though. Some are better suited to be executed inside the script server. For example timers, mathematical functions, string/list manipulation, etc. But the protocol should not be limited to LSL commands only.

The protocol should have versioning and/or some sort of capability implementation. This way server scripting support can be extended by modules on the region server, and remote script servers can utilize implementation specific functionality on region server.

A permission system for remote scripts should also be implemented so that script servers can for example get God-like access to the region server and therefore control more aspects of the world than a single script could.

==OpenSim implementation==
Originally script support in OpenSim was implemented to run scripts locally. Support for dynamically loading script engines. The same support will be extended to support stand alone remote servers, and the remote servers will be able to load the same .Net modules as OpenSim can locally.

User:Tedd Maa/stand-alone script engine

2007-10-14T21:01:04Z

Tedd Maa: New page: =Intro= My name is Tedd Hansen, SL alias Tedd Maa. I am 27 years old, live in Oslo, Norway. I run my own company with programming related project management. I have been programming since ...

=Intro=
My name is Tedd Hansen, SL alias Tedd Maa. I am 27 years old, live in Oslo, Norway. I run my own company with programming related project management. I have been programming since forever (age 7 or so).

I am working on the OpenSim project (http://www.opensimulator.org/) with main focus on programming the script engine. The OpenSim project is a BSD licensed Second Life server being developed by volunteers around the world. Many people are contributing.

I have through the OpenSim project been working with script engine implementation for some time. From the initial script engine where I did LSL ByteCode to .Net CIL (.Net assembly language) converting, to the current compiling LSL scripts to .Net assemblies (.dll).

In this document I try to argue what I think is the best way to go in script engine implementation.

Blog for my OpenSim script engine development: [http://teddmaa.blogspot.com/]

=Current script support=
==Implementation==
Current script support is in LSL2, a proprietary language with syntax similar to C#. It compiles down to a 16KB byte code that is executed on the server. Execution is done fully within that 16KB file, including stack and heap. This enables servers to easily move script between them during runtime. Because of the 16KB limit scripts can not be very large.

There is no inter process communication (communication between scripts) except public chat channels or HTTP requests to a common HTTP server. One or more scripts are put into objects, and run individually. Execution is known to be slow. Scripts are executed locally on each region where the script is running.

==Language==
The LSL2 script language consists of about 16 events and 360+ functions. The 16 events are triggers from server or from the script engine. The functions are normal functions like math/string manipulation and world manipulation. LSL2 language also has relatively advanced support for single dimension array list manipulation.

Linden Labs are planning to implement C# support through Mono. By doing this more programmers will be able to make applications, and the language syntax will be more consistent. Execution is also expected to be faster.

=Future script support=
==Multiple server implementations==
Decentralized architecture and standardization of communication protocol will spawn many different server implementations and areas of use. Scripts must be able to run on different CPU’s and operating systems. This poses a problem when a script can be moved between regions while it is executing. For that we either need a common byte code that can run on all operating systems. Most likely without JIT (Just In Time) compile to be compatible with the stack position during transfer – or a script parser execution model.

==Various use==
Currently scripts are used mainly to control objects. Because of their limitation they perform small limited functions, and only a few scripts can said to contain any complexity.
In the future I would like to see more advanced scripts.

If the limitations of scripts are removed one could develop highly complex scripts like artificial life, advanced procedural generators, environment controls, and even complex game engines that fully control all the rules of the world.

It would of course be up to the server administrator to limit the script engine and user scripts. But a script engine should not only mean “user scripts”. Server administrators should be able to write their own complex engines that control any element of the world. It should for example be possible to write script engines that create rules like Word of Warcraft, Eve Online, etc. It should even be possible to have a cluster of supercomputers running behind a single script, region or grid.
Language support
We do not want to limit the language support. People should be able to use any language, for example .Net languages, Java, C/C++ and Perl. Just like CGI scripts for web pages, the language that controls the content should not affect the presentation.

Multitasking between many scripts is a problem that needs to be handled on per script engine basis, at least in the nearest foreseeable future. If a region wants to run 10.000 .Net scripts, it is up to the script engine for .Net to do micro threading on these.

==Security==
Security in this case is a two way street. Script creators may want to protect intellectual property of your script (source code), encryption algorithms, passwords in code, access to HTTP or SQL servers, etc. Even though code might be using security through obscurity, in some cases it is more than good enough. And server administrators don’t really want foreign code running on their server.

As pointed out earlier in this document crossing region borders with the wide language support we want will be difficult. Even if it was possible it would mean that the server you were crossing into had to support your specific language. This in turn means that every script engine for every language supported needs to be 100% secure. And implementations would probably be “Allow everything then try to remove security holes”. Not something you want running on your server. The whole concept of letting anyone run a script on your server is wrong from a security perspective.

==New architecture==
Today script execution in SL is implemented into the region where the script exists. I propose adding a separate stand alone script engine to the architecture.

Whenever a script is introduced into a region, the region contacts a script server. The IP of the script engine can be determined either by default script engine for that region, user specific script engine or object/script specific script server. It may be necessary for the script to only exist on the script server and the object to contain a script reference. This way one can sell or rent scripts like virtual pets and still keep the source a secret.

Script commands that require manipulation of the world will be sent from remote script server to the region. Events from world to the object will be sent from the region to the script server. Only one connection is necessary from a region to a specific script server regardless of number of scripts (one connection can serve many scripts).

For communication I propose using a custom binary protocol that contains name of function and a dynamic number of parameters of dynamic type. If a command needs reply it should contain an ID that will be used for reply (async). This way the script server and region server can have a continuous flow of function calls going in both directions.

The basic set of commands supported on the script server should be LSL commands. Not all are required though. Some are better suited to be executed inside the script server. For example timers, mathematical functions, string/list manipulation, etc. But the protocol should not be limited to LSL commands only.

The protocol should have versioning and/or some sort of capability implementation. This way server scripting support can be extended by modules on the region server, and remote script servers can utilize implementation specific functionality on region server.

A permission system for remote scripts should also be implemented so that script servers can for example get God-like access to the region server and therefore control more aspects of the world than a single script could.

==OpenSim implementation==
Originally script support in OpenSim was implemented to run scripts locally. Support for dynamically loading script engines. The same support will be extended to support stand alone remote servers, and the remote servers will be able to load the same .Net modules as OpenSim can locally.

Architecture Working Group

2007-10-14T20:44:37Z

Tedd Maa: /* Architecture Proposals */

[[Image:slarch.jpg]]

I have gathered my tools and my charts,
My plans are finished and practical.
I shall roll up my sleeves — make Second Life over.

==Goal==

Discuss, design and implement a scalable and open architecture for the future Second Life Grid.

==Materials==

* [[Project Motivation]]
* [[Architecture Working Group Glossary|Glossary]]
* [[Use Cases]]
* [[Brainstorming]]
* [[Scoping]]
* [[Viewpoint Advocacy Groups]] (proposal)

==Architecture Proposals==
* [[Proposed Architecture|High Level Architecture proposed by Linden Lab]]
* [[Hyperplanes]]
* [[Stand-alone script engine|Tedds stand-alone script engine proposal]]

== Participating ==
Membership in this group is open. Start contribution to the work, and you become a member.
* Contribute to the materials and documentation in this wiki --- a lot of material is being drafted and discussed in the [[AW Groupies]] section (also, see below).
* Join the [http://wiki.secondlife.com/wiki/SLDev sldev mailing list] and use tags like [ARCH] and [AWG] in the subject line.
* Meet with others for technical discussions: [[User:Zero Linden|Zero Linden's]] office hours, [[AW Groupies]].

==Meetings==
Formal meetings will likely be held 3-4 times/year and located in Second Life to facilitate broad participation. Meetings will be coordinated on [[SLDev]]. Group members are encouraged to self-organize smaller meetings to move forward particular work areas and discuss hot topics as needed.

* Meeting 1
** [[ArchWG_Mtg_1_Agenda|September 13th 2007, Meeting 1]]
** [[Workitems for Meeting 1]]
** [[2007-09-13 Arch WG Minutes]]
* [[Chatlog from 2007/09/16]] (Gigs, otakup0pe and Tao_T talk about possible forms of regions etc.)
* [http://taotakashi.wordpress.com/2007/09/24/second-life-grid-architecture-meetup-transcript/ Transcript and Slides from Tao Takashi's informal meetup on 2007/09/23]
* [[In World Chatlogs]]
* [[AW Groupies]]

See also: [[User:Zero Linden|Zero Linden's office hour transcripts]]

==Individual Reviews and Feedback==

* [[ Zha's comments on meeting 1]]
* [[AWG: Zha's Desiderata for evaluating the proposed design]]
* [[ Tree's comments on meeting 1]]
* [[Diva Canto's Review]]
* [[Mic's Feedback]]
* [[Views of the Gareth]]

==Discussions==

* [[DRM, IP and permissions]] (from the mailing list)
* [[Initial CAPS seed]]
* [[AWG initial flows]]

<noinclude>
[[Category:Architecture Working Group]]</noinclude>

Architecture Working Group

2007-10-14T20:44:28Z

Tedd Maa: /* Architecture Proposals */

[[Image:slarch.jpg]]

I have gathered my tools and my charts,
My plans are finished and practical.
I shall roll up my sleeves — make Second Life over.

==Goal==

Discuss, design and implement a scalable and open architecture for the future Second Life Grid.

==Materials==

* [[Project Motivation]]
* [[Architecture Working Group Glossary|Glossary]]
* [[Use Cases]]
* [[Brainstorming]]
* [[Scoping]]
* [[Viewpoint Advocacy Groups]] (proposal)

==Architecture Proposals==
* [[Proposed Architecture|High Level Architecture proposed by Linden Lab]]
* [[Hyperplanes]]
* [[Tedds stand-alone script engine|Tedds stand-alone script engine proposal]]

== Participating ==
Membership in this group is open. Start contribution to the work, and you become a member.
* Contribute to the materials and documentation in this wiki --- a lot of material is being drafted and discussed in the [[AW Groupies]] section (also, see below).
* Join the [http://wiki.secondlife.com/wiki/SLDev sldev mailing list] and use tags like [ARCH] and [AWG] in the subject line.
* Meet with others for technical discussions: [[User:Zero Linden|Zero Linden's]] office hours, [[AW Groupies]].

==Meetings==
Formal meetings will likely be held 3-4 times/year and located in Second Life to facilitate broad participation. Meetings will be coordinated on [[SLDev]]. Group members are encouraged to self-organize smaller meetings to move forward particular work areas and discuss hot topics as needed.

* Meeting 1
** [[ArchWG_Mtg_1_Agenda|September 13th 2007, Meeting 1]]
** [[Workitems for Meeting 1]]
** [[2007-09-13 Arch WG Minutes]]
* [[Chatlog from 2007/09/16]] (Gigs, otakup0pe and Tao_T talk about possible forms of regions etc.)
* [http://taotakashi.wordpress.com/2007/09/24/second-life-grid-architecture-meetup-transcript/ Transcript and Slides from Tao Takashi's informal meetup on 2007/09/23]
* [[In World Chatlogs]]
* [[AW Groupies]]

See also: [[User:Zero Linden|Zero Linden's office hour transcripts]]

==Individual Reviews and Feedback==

* [[ Zha's comments on meeting 1]]
* [[AWG: Zha's Desiderata for evaluating the proposed design]]
* [[ Tree's comments on meeting 1]]
* [[Diva Canto's Review]]
* [[Mic's Feedback]]
* [[Views of the Gareth]]

==Discussions==

* [[DRM, IP and permissions]] (from the mailing list)
* [[Initial CAPS seed]]
* [[AWG initial flows]]

<noinclude>
[[Category:Architecture Working Group]]</noinclude>