From 29c25cb913fde0a8320bca9b9ea2cc82fbe2ec94 Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Tue, 22 Apr 2014 14:51:57 +1000 Subject: Move most of the README's and other docs into the new docs directory. --- docs/README.LuaSL | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 docs/README.LuaSL (limited to 'docs/README.LuaSL') diff --git a/docs/README.LuaSL b/docs/README.LuaSL new file mode 100644 index 0000000..1444948 --- /dev/null +++ b/docs/README.LuaSL @@ -0,0 +1,100 @@ +Refer to - http://www.infinitegrid.org/drupal/content/LuaSL_New_scripting_engine + +LuaSL is a Lua based LSL scripting engine that will aim for LSL +compatability first, then adding Lua extensions. It aims to replace the +woeful XEngine from OpenSim, and at a later stage, be the basis for a +client side scripting engine. + +To compile this, you will need Enlightenment Foundation Libraries (EFL) +installed in either /opt/e17 or /usr. These are typical places it get's +installed in. You will also need flex. The rest of the dependencies +are in the ../libraries directory. + + +Design. +------- + +The basic design will be made up as I go along, but so far I have this - + +A parser parses an LSL script, validating it and reporting errors. + +A translator takes the result of the parse, and converts it into Lua +source. Each LSL script becomes a Lua state. LSL states are handled as +Lua tables, with each LSL state function being a table function in a +common metatable. LL and OS functions are likely to be C or Lua +functions. Careful testing should be done with LuaJIT FFI, sandboxing, +and performance testing. + +The Lua source is compiled by the Lua compiler. + +LuaJIT is used as the Lua compiler, library, and runtime. + +Luaproc is used to start up operating system threads and hand Lua states +between them. Luaproc messaging is also being used, but might need to +change to edje messaging. Note - luaproc has been extensively rewritten +for this project, mostly converting it to use EFL. That rewrite +substantially shrunk the source code. More might be rewritten in +future. + +THIS IS WHERE WE ARE RIGHT NOW. + +Nails will be used to pump commands in and out of the LuaSL system. +Incoming commands invoke LSL events via the LuaSL state metatable. LL +and OS functions that impact the world will be converted to nails +commands sent to the command pump. + +Initialy, since this is the first thing being written, a nails command +pump client needs to be installed into OpenSim's C# stuff. Though it +might be possible to talk directly to ROBUST instead. Think I'll try +the ROBUST route, see how far I can get. That's the general principle +applying in all of this - try to avoid C# and see how for we can get. +lol + +On the other hand, might be better to leverage the existing C# +implementations of LSL functions, just to get things up and running +quickly. To that end, a protocol involving exchanging snippets of Lua +over a network socket has been developed, and the next step is to write +the C# side. sigh + +A watchdog thread should be used to make sure no LuaSL script spends +forever processing any event. + +Some form of serialization will need to be created for saving script +state during shutdowns, passing script state to other threads / +processes / computers. Aparently Lua is good at this. + +There will have to be a MySQL (and maybe SQLite) client in the system, +so we can talk directly to the local sim database. Esskyuehl may be +suitable, though it's still in the prototype stage. + +Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST +client will be needed to. Azy might be suitable, but it's also in +prototype. + +An object is a file system directory, full of LSL scripts as text files, +notecards as text files, animations as BVH (or later BVJ) files, etc. +There will be some sort of metadata in place. This could be created by +our own OpenSim compatible cache module. + + +Test harness. +------------- + +I'll build a test harness. It will be based on EFL Edje Lua, with +buttons for triggering LSL events, SL style dialogs, and other goodies. + +The initial goal will be to run standard MLP scripts. They have minimal +interface to the world, and exercise quite a bit of the rest of LSL. +They are also quite common, and sometimes responsible for a lot of the +script running load. + +Later I should add stock standard OpenCollar scripts from SL. They are +a bitch to get working under OpenSim, so would be good compatability +tests. + +Various eina logging domains might be used to handle whisper, say, shout, +etc. + +Performance testing will have to be done on 5000 scripts, to see how +that compares against XEngine. + -- cgit v1.1