aboutsummaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
Diffstat
-rw-r--r--ClientHamr/GuiLua/README134
-rw-r--r--README141
2 files changed, 140 insertions, 135 deletions
diff --git a/ClientHamr/GuiLua/README b/ClientHamr/GuiLua/README
index 03178e3..dc538f6 100644
--- a/ClientHamr/GuiLua/README
+++ b/ClientHamr/GuiLua/README
@@ -126,140 +126,6 @@ Lua scripts as threads, much like I'm doing with LuaSL already. Plus
126LuaJIT SPEEEEED!!. B-) 126LuaJIT SPEEEEED!!. B-)
127 127
128 128
129extantz
130 GuiLua front end for other programs it starts
131 3D rendering of multiple virtual worlds in tabs
132 including the same virtual world logged in more than once with different accounts
133 Nails interface to virtual world backend modules. Each module converts nails commands to / from it's own network protocol.
134 A SledjHamr grid, which definately should be running independantly,
135 so others can log on and stay on when extantz closes down
136 which may be a local or remote grid
137 might be part of some other grid (a sim)
138 A local only SledjHamr grid, with no other logins.
139 loaded from an on disk SledjHamr grid, or even across the 'net
140 which can be persisted as a SledjHamr grid on disk
141 An OS/SL module that connects up to OS/SL grids and translates between OS/SL networking protocols and nails / GuiLua.
142 sending OS/SL network crap to the grid in response to nails commands
143 getting OS/SL network crap from the grid
144 translating and sending nails commands to extantz so it can update it's 3D models
145 including nails encapsulated GuiLUa commands to deal the with OS/SL GUI stuff
146 An Open Croquet module.
147 importer / exporter
148 Which basically grabs an area / selected objects from the current tabs world,
149 then sends them as nails commands to -
150 a file
151 across the 'net
152 the inventory browser
153 the IAR & OAR file writer
154 or grabs one of those things listed before, and sends it as nails commands to the current tabs world
155
156LuaSL
157 socket for other programs to send scripts and other info through
158 LSL -> LuaSL compiler
159 LuaSL script runner - likely to be running thousands of scripts
160 LuaJIT to speed it up, EFL luaproc to run them as worker threads
161 LSL constants and functions implemented as a Lua library
162 The functions want to use nails to talk to the server backend.
163 Currently just sending Lua function() call strings instead.
164 The "server backend" could be OpenSim (with a shim), an actual SledjHamr server (direct nails), or extantz (direct nails).
165 The server backend is whatever is on the other end of the socket.
166 it should be able to deal with multiple socket users, but may have to fix it if it does not
167 LuaSL scripts might include LSL style GUI elements (very few, very limited)
168 convert them to and from nails encapsulated GuiLua
169 if what's on the other end of the socket is extantz, no worries
170 otherwise the other end is OpenSim, the OS end can translate GuiLua into OS/SL viewer network stuff
171 let the OS end deal with the issues. It's their fault. :-P
172 LuaSL (but not LSL) scripts could include GuiLua and other nails stuff directly.
173 Note, OpenSim being the server backend wont know what to do with GuiLua, and will only know about nails later.
174 This is just a temporary thingy anyway.
175 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.
176
177GuiLua
178 library of all the matrix-RAD type stuffs, so others can use it
179 should include the code so that proggies using it can be client, server, or both
180 including the GuiLua script runner
181 Should only be running dozens at most, and at human speeds (maybe).
182 In the end Lua is lean on resources by design, so we can afford to have lots of proggies using it all over.
183 matrix-RAD style -
184 server creates skang GUI, sends it to client
185 client deals with GUI stuff, sends values back to server
186 server stores values and does things
187 client can do things to
188
189nails command pump
190 library, including C and Lua bindings, so all can use it as client, or server, or both
191 dedicate one nails command to encapsulate GuiLua skang commands
192 "G", so GuiLua skang can look like "GuiLua.widget("name", "Button", 0, _0, 100, 4, 0, "label");"
193 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-)
194 "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.
195 The LuaSL scripts are using _LSL as the table name, but that's just using _ as an "internal variable" marker. Also easy to change.
196 SledHamr grids / sims are stored on disk or sent across the 'net as nails commands.
197
198IAR & OAR file reader / writer
199 loads up the file, sending it as nails commands
200 converts and stores incoming nails commands as an IAR or OAR file
201
202Edje Lua
203 Lua embedded in edje files, and sandboxed to them.
204 add table marshalling into an edje message
205 add host proggy supplied Lua functions
206 So we can add nails.foo(), GuiLua.foo(), and even LSL.foo().
207 LuaSL adds these to their generated scripts -
208 local _bit = require("bit")
209 local _LSL = require("LSL")
210 But require() is part of the package library that Edje Lua disables.
211 Tweak Edje Lua so that we can use it for external GuiLua and LuaSL scripts.
212 Edje Lua can add the bit library if it detects LuaJIT or 5.2.
213 This new host function thingy can be used to add GuiLua and nails ourselves. All users of it probably want to be sandboxed, the scripts should be loaded up by extantz, OpenSim, or SledjHamr, not run from the operating system.
214 LuaSL stuff needs to be sandboxed as well, maybe we can use this new host function thingy to add LSL to?
215 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.
216 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.
217 LuaJIT? Optional?
218 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.
219 Maybe Edje can use an Eina allocator?
220 LuaSL uses luaL_newstate() for now, which uses the default Lua allocator (which might be the LuaJIT one if that's in use).
221 Edje uses lua_newstate(_elua_alloc, &ela) instead.
222 merge the actual script threading code from LuaSL into Edje Lua?
223 once this code is in Edje Lua, both LuaSL and GuiLua can use that
224
225in world object editor
226 Good to be separate, coz often you spend a lot of time NOT editing.
227 GuiLua based, so it can even be replaced / hacked up / tweaked.
228 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.
229 sending nails to extantz to render the results
230 extantz sends nails to the virtual world backend modules, which deal with translating and sending them on
231 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
232
233woMan
234 account manager
235 GuiLua for dealing with the account info
236 either sending the GuiLua to extantz, or dealing with it itself
237 settings manager
238 reading legacy viewer XML GUI files for preferences
239 reading legacy viewer XML settings files
240 translating that to GuiLua
241 either sending the GuiLua to extantz, or dealing with it itself
242 writing changed settings to legacy viewer XML settings files
243
244inventory browser
245 Good to be separate, coz often you spend a lot of time NOT dealing with inventory.
246 On the other hand, people might have their inventory window open all the time, I do. lol
247 handles local inventory as the usual nails files
248
249IM client
250 Separate coz it could also be used as a normal IM client.
251 either sending the GuiLua to extantz, or dealing with it itself
252 calls libpurple for the hard work
253 needs stuff for extantz / woMan to feed it IM / group / local chat stuffs from grids
254 gotta be modular, perhaps same module that handles other grid stuff for extantz?
255 or a libpurple module for OS/SL, and have authentication credentials for those grids passed from elsewhere (woMan?)
256
257web browser
258 We may have to deal with external web proggies, which may in the end be the best way.
259 Except for MOAP. lol
260 Maybe later we can have a HTML to GuiLua translater module? Muahahaha
261
262
263skang vs edje vs LL shit 129skang vs edje vs LL shit
264------------------------ 130------------------------
265 131
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-07-04 01:37:05 +0000