1 files changed, 51 insertions, 0 deletions

diff --git a/src/sledjchisl/README b/src/sledjchisl/README
new file mode 100644
index 0000000..5d0a7b1
--- /dev/null
+++ b/src/sledjchisl/README
@@ -0,0 +1,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.