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
|
I'm re-purposing this for SledjHamr https://sledjhamr.org/git/docs/index.html
The general structure of SledjHamr is a bunch of servers talking to each
other via Internet (or just local) connections. One of them is a web
server for assets, world data, and inventory.
Originally I didn't think using a web based world client was a good idea,
however it might be better to have one, for reasons. Now I need a web
management console that can do all the things the current tmux console
can, including OpenSim console and commands. Plus account management for
users. I can also use a web based Jabber / XMPP front end to chat, IM,
and group chatter, which would run in the normal viewers web browser.
This provides a doorway into putting SledjHamr stuff in existing viewers
without needing them to support it. So a web based viewer now makes more
sense, and also means we can get away with not needing a viewer at all.
Toybox itself doesn't include a web server, and I don't think there is
one on the roadmap. So we have to use an external web server, which was
a design goal of SledjHamr in the first place, using existing mature
HTTP infrastructure, coz that's already solved problems for a bunch of
things that plague OS/SL to this day. Clear your cache! Pffft.
So sledjchisl.c will be the "love world server", though initially it just
drives OpenSim_SC in tmux via tmux commands to send keys and read output.
Later it might run opensim_SC directly and use STDIN and STDOUT to do
everything. It'll also provide the text management front end that runs
in the left tmux panel of the first window, which is why it's based on
boxes in the first place. Later still it can take over opensim_SC
functions as I move them out of mono.
We will need a text, web, and GUI version of this management front end.
Hmmm, maybe don't need a GUI version, GUI users can just run a terminal.
After much research, FastCGI / FCGI seems to be the most portable way of
interfacing with existing web servers. FCGI protocol closes STDERR and
STDOUT, and uses STDIN as it's two way communications channel to the web
server, so our FCGI module can't be used as the text management front
end. This is probably a good idea to keep them seperate anyway, for
security, coz the web server is exposed to the world, the console isn't.
Currently sledjchisl.c tests to see if it's running in tmux already, if
it isn't it starts up tmux runs itself into this new tmux, then exits.
So it could also test if it's running from FCGI, and switch to web mode,
then it'll need to find the tmuxed instance to send commands to it.
Either via nails connection, or sending tmux commands via shell.
FCGI has methods of dealing with auth and templates. B-)
So for now I think I'll have the text and web management front ends in
sledjchisl.c, and the love world server as well. I can split them up
later if I need to.
|
