1 files changed, 0 insertions, 121 deletions

diff --git a/docs/SledjHamr/README.LuaSL b/docs/SledjHamr/README.LuaSL
deleted file mode 100644
index 7556bf7..0000000
--- a/docs/SledjHamr/README.LuaSL
+++ /dev/null
@@ -1,121 +0,0 @@
-Refer to - LuaSL_New_scripting_engine.html
-
-LuaSL is a Lua based LSL scripting engine that will aim for LSL
-compatibility 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.  Then it was all rewritten again
-to use EFL threads, and cooperative multitasking.
-
-THIS IS WHERE WE ARE RIGHT NOW.
-
-Should implement embedded Lua somehow.  Probably the best thing to do is
-to have comments like -
-
-//Lua: local t = {1, 3, 42, x='something', 'something else}
-/*Lua: print(t.x) */
-
-The LSL parser picks these up and stores them in the AST as Lua
-snippets, then the compiler output functions just inserts them in the
-Lua code it is generating.  Obviously these Lua snippets can access the
-rest of the generated Lua code.  They should also be able to access
-skang and thus do proper GUI stuff on viewers that support skang.
-
-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.
-
-Initially, 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.  Apparently 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.
-
-The test harness became the love world server.
-
-
-TODO
-----
-
-Useful for limiting the amount of time scripts use -
-https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE
-http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly