OpenSim (OS) and Second Life (SL) technology leave a lot to be desired. If they are ever going to take off, there needs to be a serious redesign. However, writing an entire virtual world system from scratch is a huge job, especially for a tiny team. So we will use the existing OS and SL open source software as crutches, using them to run at least one virtual world, while we slowly replace bits and pieces as we get to them. In this way, we can have our cake and eat it to. Not having to slave away for years just to get to the point where we have a single avatar standing still in an empty world. http://www.infinitegrid.org/drupal/content/OMG discusses our plans. The 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. 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?