Add the SledjChisl stuff.

1 files changed, 118 insertions, 0 deletions

diff --git a/src/sledjchisl/README b/src/sledjchisl/README
new file mode 100644
index 0000000..31a4b30
--- /dev/null
+++ b/src/sledjchisl/README
@@ -0,0 +1,118 @@
+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.  Actually most of OpenSim
+is just a collection of web servers.
+
+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.
+
+
+--------------------------------------------------------------------
+
+How to install it.
+------------------
+
+It's all still partly written, un-released, and experimental at the
+moment.  So thes are just rough notes about what is needed.
+
+There are two parts, the OpenSim runner part and the web pages part.  The
+OpenSim runner part requjires the rest of opensim-SC to be installed,
+which is covered by other documents in this source code repo.  SO the
+below only talks about the web pages part.
+
+So far I have only tried this with Apache 2, but it should work fine with
+other web servers that support FCGI.  I'm using spawn-fcgi which was
+written for lighttpd, and seems to be the proper way to support FCGI in
+Nginx as well.
+
+Until I have actually released this, it'll be source code only.  So you
+need a C development environment to compile all the C source code.
+
+Some of the dependencies are included, like LuaJIT, qLibc, the FCGI SDK,
+and toybox.  Or at least their source code git ropes are cloned during
+the build stage.  The other dependencies are the development environments
+for MariaDB or MySQL (only tested with MariaDB), OpenSSL, and UUID.  And
+spawn-fcgi.  In a Debian based Linux distro, that could be installed by
+something like -
+
+apt install libmariadbclient-dev libssl1.0-dev uuid-dev spawn-fcgi
+
+Once you have all of that, you can run the src/BuildIt.sh script to put
+it all together.  That script will also actually run the web side of
+things.  Often during this early development process, that script will
+run things under a test tool like valgrind, so you'll probably need that
+to.
+
+You'll need to configure your web server to pass web requests onto
+sledjchisl.  I'll add instructions for other popular web servers later,
+but for now, this is what to do with Apache 2.
+
+Load the mod_proxy_fcgi module.  Include something like this in your
+virtual host definition -
+
+<FilesMatch "\.fcgi$">
+  SetHandler "proxy:unix:///opt/opensim_SC/var/cache/sledjchisl.socket|fcgi://localhost/"
+</FilesMatch>
+
+Adjust that unix:// path to match if you have installed things elsewhere. 
+Also make that directory readable by the web server group.
+
+Copy the files in example/www to where eveqer your web servers document
+root is.
+
+Note that the account.html dynamic web page redirects to a HTTPS version
+of itself, so you'll need HTTPS to be working.
+
+The current web pages will then be available at something like -
+
+http://localhost/sledjchisl.fcgi/loginpage.html
+
+http://localhost/sledjchisl.fcgi/stats.html
+
+https://localhost/sledjchisl.fcgi/account.html
+