Move most of the README's and other docs into the new docs directory.

1 files changed, 100 insertions, 0 deletions

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.
+