1 files changed, 93 insertions, 0 deletions

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