More design notes.

3 files changed, 108 insertions, 7 deletions

diff --git a/LuaSL/README b/LuaSL/README
index 7eb9ce0..cf5f9ae 100644
--- a/LuaSL/README
+++ b/LuaSL/README
@@ -19,7 +19,8 @@ The basic design will be made up as I go along, but so far I have this -
 
 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.
+There will be some sort of metadata in place.  This could be created by
+our own OpenSim compatible cache module.
 
 A parser parses an LSL script, validating it and reporting errors.
 
@@ -34,8 +35,9 @@ 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 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.
 
 Nails is used to pump commands in and out of the LuaSL system.  Incoming
 commands invoke LSL events via the LuaSL state metatable.  LL and OS
@@ -45,7 +47,7 @@ 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 hov far I can get.  That's the general principle
+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
 
@@ -56,6 +58,14 @@ Some form of serialization will need to be created for saving script
 state during shutdowns, passing script state to other threads /
 processes / computers.
 
+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.
+
 
 Test harness.
 -------------
diff --git a/LuaSL/src/LuaSL_compile.c b/LuaSL/src/LuaSL_compile.c
index 29ea47c..a65b84b 100644
--- a/LuaSL/src/LuaSL_compile.c
+++ b/LuaSL/src/LuaSL_compile.c
@@ -2276,9 +2276,7 @@ boolean compileLSL(gameGlobals *game, char *script, boolean doConstants)
                 fprintf(out, "--// Generated code goes here.\n\n");
                 fprintf(out, "local _bit = require(\"bit\")\n");
                 fprintf(out, "local _LSL = require(\"LSL\")\n\n");
-                // TODO - Use the scripts UUID instead of the file name here.
-                // Hmm, copies of the same script in the same prim would have the same UUID, but different name, though they would run independently.
-                // Copies of the same script in different prims could have the same UUID AND the same name.
+                // TODO - Use the scripts UUID instead of the file name here, or something.
                 fprintf(out, "local _SID = [=[%s.lua.out]=]\n\n", compiler.fileName);
                 outputLeaf(out, OM_LUA, compiler.ast);
                 fprintf(out, "\n\n_LSL.mainLoop(_SID, _defaultState)\n");  // This actually starts the script running.
diff --git a/LuaSL/src/LuaSL_runner.c b/LuaSL/src/LuaSL_runner.c
index a59855d..5bb5e7a 100644
--- a/LuaSL/src/LuaSL_runner.c
+++ b/LuaSL/src/LuaSL_runner.c
@@ -159,3 +159,96 @@ void runnerTearDown(gameGlobals *game)
 // TODO - this is what hangs the system.
     sched_join_workerthreads();
 }
+
+
+/* What we need to do, and how we might do it.
+ *
+ * Get configuration info.
+ *
+ *   Some of the configuration info we need is tucked away in OpenSim .ini files.  So we have to read that.
+ *   Eet is probably not so useful here, as we would have to write a UI tool, and there's no UI otherwise.
+ *
+ * Multi task!
+ *
+ *   Luaproc starts up X worker threads.  Each one takes the next ready Lua state and runs it until it blocks waiting for a channel message, or yields.
+ *   The current mainloop waits for events and commands from the message channel, executes them, then goes back to waiting.
+ *   So that is fine in general, so long as the LSL event handlers actually return in a reasonable time.
+ *   We need to be able to yield at suitable places, or be able to force a yield.  Both without slowing things down too much.
+ *
+ * Watchdog thread.
+ *
+ *   It's easy enough to have a watchdog thread wake up every now and then to check if any given Lua state has been hogging it's CPU for too long.
+ *   The hard part is forcing Lua states to yield cleanly, without slowing performance too much.
+ *
+ * Identifying scripts.
+ *
+ *   We need to be able to identify scripts so that messages can get to the right ones.  Also the objects they are in.
+ *   And do it all in a way that OpenSim is happy with.
+ *   Copies of the same script in the same prim would have the same UUID, but different name, though they would run independently.
+ *   Copies of the same script in different prims could have the same UUID AND the same name.
+ *
+ * Script start, stop, reset.
+ *
+ *   Scripts and users have to be able to start, stop, and reset scripts.
+ *   Users have to be able to see the start / stopped status of scripts from the viewer.
+ *   Which means if the script does it, we have to tell OpenSim.
+ *   Naturally, if OpenSim does it, it has to tell us.
+ *   Should be able to do both by passing textual Lua function calls between OpenSim and LuaSL.
+ *
+ * Event handling, llDetect*() functions.
+ *
+ *   OpenSim will generate events at random times and send us relevant information for llDetect*() functions and the handler calls.
+ *   These should come through the scripts main loop eventually.
+ *
+ * Send messages from / to OpenSim and ROBUST.
+ *
+ *   ROBUST uses HTTP for the communications, and some sort of XML, probably XML-RPC.
+ *   OpenSim has some sort of generic mechanism for talking to script engines in C#.  I want to turn that into a socket based, pass textual Lua function calls, type system.
+ *     That assumes C# has some sort of semi decent introspection or reflection system.
+ *     The scripts main loop can already deal with incoming commands as a string with a Lua function call in it.
+ *
+ * Send messages from / to Lua or C, and wait or not wait.
+ *
+ *   Luaproc channels are distinct from Lua states, but some Lua state has to create them before they can be used.
+ *     On the other hand, looks like broadcasting messages is not really catered for, it's first come first served.
+ *   luaproc.send() can send multiple messages to a single channel.  It blocks if no one is listening.
+ *     This was done to simplify things for the luaproc programmers, who suggest creating more Lua states to deal with asynchronous message sending.
+ *   luaprog.receive() gets a channel message.  It can block waiting, or not block.
+ *   I already hacked up C code to send and not block.  I might have broken the luaproc.send() ability to send multiple messages.
+ *     Before I hacked it up, actual message sending was done by copying the contents of the sending Lua states stack to the receiver states stack.
+ *     This is the simple method for the luaproc programmers, as both states are in the context of a luaproc call, so both stacks are available.
+ *     My hacked up version either takes one message from the sender, or is passed one from C.  The C call just returns if there is no one waiting on that channel.
+ *     luaproc.send() cals that C function after taking a single message from the stack, and block waits as usual if the C call cannot deliver.
+ *   Don't think there is C to receive messages, luaproc seems to be lacking entirely in C side API.
+ *   Edje messages might have to be used instead, or some hybrid.
+ *
+ * Time and timers, plus deal with time dilation.
+ *
+ *   Various LSL functions deal with time, that's no problem.
+ *   Some might deal with time dilation, which means dealing with that info through OpenSim.
+ *   There is a timer event, which should be done through ecore timers and whatever message system we end up with.
+ *   Finally, a sleep call, which can be done with ecore timer and messages to.
+ *
+ * Deal directly with MySQL and SQLite databases.
+ *
+ *   The script engine can run on the same computer as the sim server, that's how OpenSim does stuff.  So we can directly access the database the sim server has, which gives us access to sim object metadata.
+ *   Changing that metadata might require us to inform OpenSim about the changes.  It's entirely possible that different changes do or do not need that.
+ *   Esskyuehl may be suitable, though it's still in the prototype stage.
+ *
+ * Serialise the script state, send it somewhere.
+ *
+ *   Lua can generally serialise itself as as a string of code to be executed at the destination.  There might be some C side state that needs to be take care of as well.  We shall see.
+ *
+ * Email, HTTP, XML-RPC?
+ *
+ *   LSL has functions for using these as communications methods.  We should implement them ourselves eventually, but use the existing OpenSim methods for now.
+ *   Note that doing it ourselves may cause issues with OpenSim doing it for some other script engine.
+ *   Azy might be suitable, but it's also in prototype.
+ *
+ * Object inventory "cache".
+ *
+ *   This code currently pretends that there is a local file based sim object store available.
+ *   I think it would be a good idea to abuse the OpenSim cache system to produce that file based object store.
+ *   It will help with the "damn OpenSim's asset database has to be a bottomless pit" monster design flaw.
+ *
+*/