From e1e17a1bbd63b632cf28309764e83d661edaaaea Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Sun, 3 Feb 2013 20:38:30 +1000 Subject: Shift some of the docn around. --- README | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 140 insertions(+), 1 deletion(-) (limited to 'README') diff --git a/README b/README index f1fbd0b..fe91a89 100644 --- a/README +++ b/README @@ -13,4 +13,143 @@ directory structure in here more or less follows the names of those documents. It's all very experimental at the moment, and currently does nothing -useful. \ No newline at end of file +useful. + + +The bits (or some of them). +--------------------------- + +extantz + GuiLua front end for other programs it starts + 3D rendering of multiple virtual worlds in tabs + including the same virtual world logged in more than once with different accounts + Nails interface to virtual world backend modules. Each module converts nails commands to / from it's own network protocol. + A SledjHamr grid, which definately should be running independantly, + so others can log on and stay on when extantz closes down + which may be a local or remote grid + might be part of some other grid (a sim) + A local only SledjHamr grid, with no other logins. + loaded from an on disk SledjHamr grid, or even across the 'net + which can be persisted as a SledjHamr grid on disk + An OS/SL module that connects up to OS/SL grids and translates between OS/SL networking protocols and nails / GuiLua. + sending OS/SL network crap to the grid in response to nails commands + getting OS/SL network crap from the grid + translating and sending nails commands to extantz so it can update it's 3D models + including nails encapsulated GuiLUa commands to deal the with OS/SL GUI stuff + An Open Croquet module. + importer / exporter + Which basically grabs an area / selected objects from the current tabs world, + then sends them as nails commands to - + a file + across the 'net + the inventory browser + the IAR & OAR file writer + or grabs one of those things listed before, and sends it as nails commands to the current tabs world + +GuiLua + library of all the matrix-RAD type stuffs, so others can use it + should include the code so that proggies using it can be client, server, or both + including the GuiLua script runner + Should only be running dozens at most, and at human speeds (maybe). + In the end Lua is lean on resources by design, so we can afford to have lots of proggies using it all over. + matrix-RAD style - + server creates skang GUI, sends it to client + client deals with GUI stuff, sends values back to server + server stores values and does things + client can do things to + +Edje Lua + Lua embedded in edje files, and sandboxed to them. + add table marshalling into an edje message + add host proggy supplied Lua functions + So we can add nails.foo(), GuiLua.foo(), and maybe even LSL.foo(). + All users of GuiLua and nails probably want to be sandboxed, the scripts should be loaded up by extantz, OpenSim, or SledjHamr, not run from the operating system. + LuaSL adds these to their generated scripts - + local _bit = require("bit") + local _LSL = require("LSL") + But require() is part of the package library that Edje Lua disables. + Tweak Edje Lua so that we can use it for external GuiLua and LuaSL scripts. + Edje Lua can add the bit library if it detects LuaJIT or 5.2. + LuaSL stuff needs to be sandboxed as well, maybe we can use this new host function thingy to add LSL to? + Really should investigate if this shit being duplicated in thousands of LuaSL scripts soaks up lots of memory? And require("LSL") versus this new host function thingy. + On the other hand, a lot oy this LSL library would end up being wrappers around nails in the future, which is a shared library. + LuaJIT? Optional? + Need to sort out it's memory allocator, coz apparently the one Edje uses is not thread safe, but the LuaJIT one does not limit memory per script like Edje does. + Maybe Edje can use an Eina allocator? + LuaSL uses luaL_newstate() for now, which uses the default Lua allocator (which might be the LuaJIT one if that's in use). + Edje uses lua_newstate(_elua_alloc, &ela) instead. + merge the actual script threading code from LuaSL into Edje Lua? + once this code is in Edje Lua, both LuaSL and GuiLua can use that + +woMan + account manager + GuiLua for dealing with the account info + either sending the GuiLua to extantz, or dealing with it itself + settings manager + reading legacy viewer XML GUI files for preferences + reading legacy viewer XML settings files + translating that to GuiLua + either sending the GuiLua to extantz, or dealing with it itself + writing changed settings to legacy viewer XML settings files + +in world object editor + Good to be separate, coz often you spend a lot of time NOT editing. + GuiLua based, so it can even be replaced / hacked up / tweaked. + Probably not much point dealing with GUI itself, as you want a 3D rendering of what you are editing, thus need extantz as the front end. + sending nails to extantz to render the results + extantz sends nails to the virtual world backend modules, which deal with translating and sending them on + also gotta deal with OS/SL backends that prefer to send the entire thing round robin and only update the screen once it's hit the server + +inventory browser + Good to be separate, coz often you spend a lot of time NOT dealing with inventory. + On the other hand, people might have their inventory window open all the time, I do. lol + handles local inventory as the usual nails files + +LuaSL + socket for other programs to send scripts and other info through + LSL -> LuaSL compiler + LuaSL script runner - likely to be running thousands of scripts + LuaJIT to speed it up, EFL luaproc to run them as worker threads + LSL constants and functions implemented as a Lua library + The functions want to use nails to talk to the server backend. + Currently just sending Lua function() call strings instead. + The "server backend" could be OpenSim (with a shim), an actual SledjHamr server (direct nails), or extantz (direct nails). + The server backend is whatever is on the other end of the socket. + it should be able to deal with multiple socket users, but may have to fix it if it does not + LuaSL scripts might include LSL style GUI elements (very few, very limited) + convert them to and from nails encapsulated GuiLua + if what's on the other end of the socket is extantz, no worries + otherwise the other end is OpenSim, the OS end can translate GuiLua into OS/SL viewer network stuff + let the OS end deal with the issues. It's their fault. :-P + LuaSL (but not LSL) scripts could include GuiLua and other nails stuff directly. + Note, OpenSim being the server backend wont know what to do with GuiLua, and will only know about nails later. + This is just a temporary thingy anyway. + Might be able to convert it to use more generalised message parsing, PLUS teach Edje some of LuaSL's message parsing tricks. Find a happy medium. + +nails command pump + library, including C and Lua bindings, so all can use it as client, or server, or both + dedicate one nails command to encapsulate GuiLua skang commands + "G", so GuiLua skang can look like "GuiLua.widget("name", "Button", 0, _0, 100, 4, 0, "label");" + could even have a nails command for Lua / LuaSL / LSL commands or scripts. This might help with the OpenSim nails shim, we can start with that, and expand it later. B-) + "L" and "l", though currently LuaSL is using SID.foo(), where SID is the UUID of the script. Easy enough to whack an L in front of that. + The LuaSL scripts are using _LSL as the table name, but that's just using _ as an "internal variable" marker. Also easy to change. + SledHamr grids / sims are stored on disk or sent across the 'net as nails commands. + +IM client + Separate coz it could also be used as a normal IM client. + either sending the GuiLua to extantz, or dealing with it itself + calls libpurple for the hard work + needs stuff for extantz / woMan to feed it IM / group / local chat stuffs from grids + gotta be modular, perhaps same module that handles other grid stuff for extantz? + or a libpurple module for OS/SL, and have authentication credentials for those grids passed from elsewhere (woMan?) + +web browser + We may have to deal with external web proggies, which may in the end be the best way. + Except for MOAP. lol + Maybe later we can have a HTML to GuiLua translater module? Muahahaha + +IAR & OAR file reader / writer + loads up the file, sending it as nails commands + converts and stores incoming nails commands as an IAR or OAR file + Could cover Impy exports as well as others? + -- cgit v1.1