diff options
Diffstat (limited to 'LuaSL/README')
-rw-r--r-- | LuaSL/README | 65 |
1 files changed, 64 insertions, 1 deletions
diff --git a/LuaSL/README b/LuaSL/README index 2236bae..7dbf922 100644 --- a/LuaSL/README +++ b/LuaSL/README | |||
@@ -1 +1,64 @@ | |||
1 | Refer to - http://wiki.infinitegrid.org/index.php/LuaSL_-_New_scripting_engine \ No newline at end of file | 1 | Refer to - http://wiki.infinitegrid.org/index.php/LuaSL_-_New_scripting_engine |
2 | |||
3 | LuaSL is a Lua based LSL scripting engine that will aim for LSL | ||
4 | compatability first, then adding Lua extensions. It aims to replace the | ||
5 | woeful XEngine from OpenSim, and at a later stage, be the basis for a | ||
6 | client side scripting engine. | ||
7 | |||
8 | |||
9 | Design. | ||
10 | ------- | ||
11 | |||
12 | The basic design will be made up as I go along, but so far I have this - | ||
13 | |||
14 | An object is a file system directory, full of LSL scripts as text files, | ||
15 | notecards as text files, animations as BVH (or later BVJ) files, etc. | ||
16 | There will be some sort of metadata in place. | ||
17 | |||
18 | A parser parses an LSL script, validating it and reporting errors. | ||
19 | |||
20 | A preprocessor takes the result of the parse, and converts it into Lua | ||
21 | source. Each LSL script becomes a Lua state. LSL states are handled as | ||
22 | Lua tables, with each LSL state function being a table function in a | ||
23 | common metatable. LL and OS functions are likely to be C functions. | ||
24 | Careful testing should be done with LuaJIT FFI, sandboxing, and | ||
25 | performance testing. | ||
26 | |||
27 | The Lua source is compiled by the Lua compiler. | ||
28 | |||
29 | LuaJIT is used as the Lua compiler, library, and runtime. | ||
30 | |||
31 | Luaproc is used to start up operating system threads and hand Lua | ||
32 | states between them. | ||
33 | |||
34 | Nails is used to pump commands in and out of the LuaSL system. Incoming | ||
35 | commands invoke LSL events via the LuaSL state metatable. LL and OS | ||
36 | functions that impact the world will be converted to nails commands sent | ||
37 | to the command pump. | ||
38 | |||
39 | A watchdog thread is used to make sure no LuaSL script spends forever | ||
40 | processing any event. | ||
41 | |||
42 | Some form of serialization will need to be created for saving script | ||
43 | state during shutdowns, passing script state to other threads / | ||
44 | processes / computers. | ||
45 | |||
46 | |||
47 | Test harness. | ||
48 | ------------- | ||
49 | |||
50 | I'll build a test harness. It will be based on EFL Edje Lua, with | ||
51 | buttons for triggering LSL events, SL style dialogs, and other goodies. | ||
52 | |||
53 | The initial goal will be to run standard MLP scripts. They have minimal | ||
54 | interface to the world, and exercise quite a bit of the rest of LSL. | ||
55 | They are also quite common, and sometimes responsible for a lot of the | ||
56 | script running load. | ||
57 | |||
58 | Various eina logging domains will be used to handle whisper, say, shout, | ||
59 | etc. | ||
60 | |||
61 | Performance testing will have to be done on 5000 scripts, to see how | ||
62 | that compares against XEngine. | ||
63 | |||
64 | |||