User talk:Tedd Maa/stand-alone script engine

• 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.) --Morgaine Dinova 04:18, 15 October 2007 (PDT)

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.