1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
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?
|
