I have finished the new API for loading and parsing scripts in the
ScriptingService. The main idea is that you can mix statements, functions,
programs and statemachines in any order in a single file. Top-level statements
are executed immediately (during the parsing!). programs, functions and
statemachines are only parsed as usual, but available for later use (in the
same file or future files).

This API consists of these two functions:

eval(" ...code... ")
runScript("filename.ops")

and deprecates loadStateMachines/loadPrograms/loadFunctions/execute. You can
load your existing programs and statemachines using the runScript function.

Immediate advantages are:
* being able to define functions in the same file as statemachines
* being able to start a program/statemachine from the same file where it is
defined
* being able to write deployment scripts that first 'import()' packages, then
load components and finally connect and start everything (using a statemachine,
program etc) all in the same file, or by recursively calling eval/runScript in
order to delegate code to other scripts.

I propose to extend the deployer with 'runScript'/'eval' functions that take a
service and a filename as arguments which allows the deployer to load that
service and pass it the file or code snippet. This should then work for both
Lua and RTT scripting scenarios. The same XML elements would be available too
for the same purpose.

I believe something like that is in the making for Lua already, so I hope it's
just a matter of merging/streamlining.

This is about how far I'm willing to take RTT scripting. Complexer scenarios
must be expressed in Lua. The only[1] hanging issue is the statemachine event
scenario, which should be made more/better compatible with 1.x architectures,
but I still have no concrete solution or target date for that feature.

You can test all this by checking out rtt master, loading the scripting
service in the deployer and use its api, like in
'scripting.eval("kickStart(\"test.xml\")")'
or
'scripting.runScript("file.ops")'

Peter

[1] The other hanging issue is the lack of a 'print' statement built-into the
language and the lack of '++' and '+=' style operators :-)