aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/README
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--README141
1 files changed, 140 insertions, 1 deletions
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
13documents. 13documents.
14 14
15It's all very experimental at the moment, and currently does nothing 15It's all very experimental at the moment, and currently does nothing
16useful. \ No newline at end of file 16useful.
17
18
19The bits (or some of them).
20---------------------------
21
22extantz
23 GuiLua front end for other programs it starts
24 3D rendering of multiple virtual worlds in tabs
25 including the same virtual world logged in more than once with different accounts
26 Nails interface to virtual world backend modules. Each module converts nails commands to / from it's own network protocol.
27 A SledjHamr grid, which definately should be running independantly,
28 so others can log on and stay on when extantz closes down
29 which may be a local or remote grid
30 might be part of some other grid (a sim)
31 A local only SledjHamr grid, with no other logins.
32 loaded from an on disk SledjHamr grid, or even across the 'net
33 which can be persisted as a SledjHamr grid on disk
34 An OS/SL module that connects up to OS/SL grids and translates between OS/SL networking protocols and nails / GuiLua.
35 sending OS/SL network crap to the grid in response to nails commands
36 getting OS/SL network crap from the grid
37 translating and sending nails commands to extantz so it can update it's 3D models
38 including nails encapsulated GuiLUa commands to deal the with OS/SL GUI stuff
39 An Open Croquet module.
40 importer / exporter
41 Which basically grabs an area / selected objects from the current tabs world,
42 then sends them as nails commands to -
43 a file
44 across the 'net
45 the inventory browser
46 the IAR & OAR file writer
47 or grabs one of those things listed before, and sends it as nails commands to the current tabs world
48
49GuiLua
50 library of all the matrix-RAD type stuffs, so others can use it
51 should include the code so that proggies using it can be client, server, or both
52 including the GuiLua script runner
53 Should only be running dozens at most, and at human speeds (maybe).
54 In the end Lua is lean on resources by design, so we can afford to have lots of proggies using it all over.
55 matrix-RAD style -
56 server creates skang GUI, sends it to client
57 client deals with GUI stuff, sends values back to server
58 server stores values and does things
59 client can do things to
60
61Edje Lua
62 Lua embedded in edje files, and sandboxed to them.
63 add table marshalling into an edje message
64 add host proggy supplied Lua functions
65 So we can add nails.foo(), GuiLua.foo(), and maybe even LSL.foo().
66 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.
67 LuaSL adds these to their generated scripts -
68 local _bit = require("bit")
69 local _LSL = require("LSL")
70 But require() is part of the package library that Edje Lua disables.
71 Tweak Edje Lua so that we can use it for external GuiLua and LuaSL scripts.
72 Edje Lua can add the bit library if it detects LuaJIT or 5.2.
73 LuaSL stuff needs to be sandboxed as well, maybe we can use this new host function thingy to add LSL to?
74 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.
75 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.
76 LuaJIT? Optional?
77 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.
78 Maybe Edje can use an Eina allocator?
79 LuaSL uses luaL_newstate() for now, which uses the default Lua allocator (which might be the LuaJIT one if that's in use).
80 Edje uses lua_newstate(_elua_alloc, &ela) instead.
81 merge the actual script threading code from LuaSL into Edje Lua?
82 once this code is in Edje Lua, both LuaSL and GuiLua can use that
83
84woMan
85 account manager
86 GuiLua for dealing with the account info
87 either sending the GuiLua to extantz, or dealing with it itself
88 settings manager
89 reading legacy viewer XML GUI files for preferences
90 reading legacy viewer XML settings files
91 translating that to GuiLua
92 either sending the GuiLua to extantz, or dealing with it itself
93 writing changed settings to legacy viewer XML settings files
94
95in world object editor
96 Good to be separate, coz often you spend a lot of time NOT editing.
97 GuiLua based, so it can even be replaced / hacked up / tweaked.
98 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.
99 sending nails to extantz to render the results
100 extantz sends nails to the virtual world backend modules, which deal with translating and sending them on
101 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
102
103inventory browser
104 Good to be separate, coz often you spend a lot of time NOT dealing with inventory.
105 On the other hand, people might have their inventory window open all the time, I do. lol
106 handles local inventory as the usual nails files
107
108LuaSL
109 socket for other programs to send scripts and other info through
110 LSL -> LuaSL compiler
111 LuaSL script runner - likely to be running thousands of scripts
112 LuaJIT to speed it up, EFL luaproc to run them as worker threads
113 LSL constants and functions implemented as a Lua library
114 The functions want to use nails to talk to the server backend.
115 Currently just sending Lua function() call strings instead.
116 The "server backend" could be OpenSim (with a shim), an actual SledjHamr server (direct nails), or extantz (direct nails).
117 The server backend is whatever is on the other end of the socket.
118 it should be able to deal with multiple socket users, but may have to fix it if it does not
119 LuaSL scripts might include LSL style GUI elements (very few, very limited)
120 convert them to and from nails encapsulated GuiLua
121 if what's on the other end of the socket is extantz, no worries
122 otherwise the other end is OpenSim, the OS end can translate GuiLua into OS/SL viewer network stuff
123 let the OS end deal with the issues. It's their fault. :-P
124 LuaSL (but not LSL) scripts could include GuiLua and other nails stuff directly.
125 Note, OpenSim being the server backend wont know what to do with GuiLua, and will only know about nails later.
126 This is just a temporary thingy anyway.
127 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.
128
129nails command pump
130 library, including C and Lua bindings, so all can use it as client, or server, or both
131 dedicate one nails command to encapsulate GuiLua skang commands
132 "G", so GuiLua skang can look like "GuiLua.widget("name", "Button", 0, _0, 100, 4, 0, "label");"
133 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-)
134 "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.
135 The LuaSL scripts are using _LSL as the table name, but that's just using _ as an "internal variable" marker. Also easy to change.
136 SledHamr grids / sims are stored on disk or sent across the 'net as nails commands.
137
138IM client
139 Separate coz it could also be used as a normal IM client.
140 either sending the GuiLua to extantz, or dealing with it itself
141 calls libpurple for the hard work
142 needs stuff for extantz / woMan to feed it IM / group / local chat stuffs from grids
143 gotta be modular, perhaps same module that handles other grid stuff for extantz?
144 or a libpurple module for OS/SL, and have authentication credentials for those grids passed from elsewhere (woMan?)
145
146web browser
147 We may have to deal with external web proggies, which may in the end be the best way.
148 Except for MOAP. lol
149 Maybe later we can have a HTML to GuiLua translater module? Muahahaha
150
151IAR & OAR file reader / writer
152 loads up the file, sending it as nails commands
153 converts and stores incoming nails commands as an IAR or OAR file
154 Could cover Impy exports as well as others?
155
generated by cgit v1.1 at 2024-11-19 17:57:11 +0000