From 7341af59640b65d409a09bec1ff891bd9e40b8ca Mon Sep 17 00:00:00 2001
From: David Walter Seikel
Date: Thu, 18 Feb 2016 13:24:40 +1000
Subject: Shift some docs around, and link to them.
---
docs/README.Bookie | 33 -----
docs/README.HamrSpace | 1 -
docs/README.Lspace | 3 -
docs/README.LuaSL | 121 -----------------
docs/README.REST | 2 -
docs/README.WTF | 5 -
docs/README.libraries | 34 -----
docs/README.nails | 14 --
docs/SledjHamr/README.Bookie | 33 +++++
docs/SledjHamr/README.HamrSpace | 1 +
docs/SledjHamr/README.Lspace | 3 +
docs/SledjHamr/README.LuaSL | 121 +++++++++++++++++
docs/SledjHamr/README.REST | 2 +
docs/SledjHamr/README.WTF | 5 +
docs/SledjHamr/README.libraries | 34 +++++
docs/SledjHamr/README.nails | 14 ++
docs/SledjHamr/The_Naminator.txt | 14 ++
docs/SledjHamr/love.txt | 271 +++++++++++++++++++++++++++++++++++++++
docs/SledjHamr/no_accounts.txt | 29 +++++
docs/SledjHamr/portals.txt | 106 +++++++++++++++
docs/SledjHamr/privacy.txt | 5 +
docs/The_Naminator.txt | 14 --
docs/index.html | 2 +-
docs/love.txt | 271 ---------------------------------------
docs/no_accounts.txt | 29 -----
docs/portals.txt | 106 ---------------
docs/privacy.txt | 5 -
27 files changed, 639 insertions(+), 639 deletions(-)
delete mode 100644 docs/README.Bookie
delete mode 100644 docs/README.HamrSpace
delete mode 100644 docs/README.Lspace
delete mode 100644 docs/README.LuaSL
delete mode 100644 docs/README.REST
delete mode 100644 docs/README.WTF
delete mode 100644 docs/README.libraries
delete mode 100644 docs/README.nails
create mode 100644 docs/SledjHamr/README.Bookie
create mode 100644 docs/SledjHamr/README.HamrSpace
create mode 100644 docs/SledjHamr/README.Lspace
create mode 100644 docs/SledjHamr/README.LuaSL
create mode 100644 docs/SledjHamr/README.REST
create mode 100644 docs/SledjHamr/README.WTF
create mode 100644 docs/SledjHamr/README.libraries
create mode 100644 docs/SledjHamr/README.nails
create mode 100644 docs/SledjHamr/The_Naminator.txt
create mode 100644 docs/SledjHamr/love.txt
create mode 100644 docs/SledjHamr/no_accounts.txt
create mode 100644 docs/SledjHamr/portals.txt
create mode 100644 docs/SledjHamr/privacy.txt
delete mode 100644 docs/The_Naminator.txt
delete mode 100644 docs/love.txt
delete mode 100644 docs/no_accounts.txt
delete mode 100644 docs/portals.txt
delete mode 100644 docs/privacy.txt
(limited to 'docs')
diff --git a/docs/README.Bookie b/docs/README.Bookie
deleted file mode 100644
index bec4b19..0000000
--- a/docs/README.Bookie
+++ /dev/null
@@ -1,33 +0,0 @@
-Shared dynamic libraries is a bit of an issue for cross platform code.
-LL viewers deal with it by including their own copies of the libraries
-they use. This bypasses the idea of sharing them, and thus uses too
-much resources. On the other hand, it seems to be the Windows way of
-doing things, lots of Windows packages I have seen include their own
-copies of libraries. Mac Os X seems to do the same, each application is
-installed as it's own directory, filled with it's own copies of
-libraries. Not a lot of sharing going on. Linux and the BSDs do the
-right thing, most libraries are actually shared. Except that LL viewers
-STILL bring their own libraries.
-
-I think the main difference is having a proper package management
-system. Apt, RPM, and portage (I think) can track dependencies on
-libraries, install the libraries automatically, and even have different
-versions of libraries installed side by side. Without this, the OS has
-no official way of tracking library dependencies, so every one has to
-supply their own. Sure Mac OS X has had a few package systems ported to
-it, but none of them are the official one, so developers can't rely on
-them.
-
-SledjHamr has to deal with this, and try to do so in some sort of smart
-way. As usual, the right way to do things is generally to do the
-opposite of what LL does. lol
-
-Bookie should be a sub system that probes the OS, trying to see if
-there's some sort of OS store of libraries, and try to find reasonable
-versions of the libraries needed in that. If not found, it could invoke
-an OS specific method of installing a suitable library. If that fails,
-it can download a SledjHamr specific version into the SledjHamr
-installed directory. So it tries to do the right thing first, and
-gradually falls back to doing the wrong thing like LL does.
-
-That's the theory, in practice, gonna be a pain.
diff --git a/docs/README.HamrSpace b/docs/README.HamrSpace
deleted file mode 100644
index a2e19cf..0000000
--- a/docs/README.HamrSpace
+++ /dev/null
@@ -1 +0,0 @@
-Inventory server.
diff --git a/docs/README.Lspace b/docs/README.Lspace
deleted file mode 100644
index 2eb9b24..0000000
--- a/docs/README.Lspace
+++ /dev/null
@@ -1,3 +0,0 @@
-Sim contents server, which is pretty much a web server. Should support
-WebDAV so people can point their file browsers at it. More details in
-love.txt.
diff --git a/docs/README.LuaSL b/docs/README.LuaSL
deleted file mode 100644
index 7556bf7..0000000
--- a/docs/README.LuaSL
+++ /dev/null
@@ -1,121 +0,0 @@
-Refer to - LuaSL_New_scripting_engine.html
-
-LuaSL is a Lua based LSL scripting engine that will aim for LSL
-compatibility first, then adding Lua extensions. It aims to replace the
-woeful XEngine from OpenSim, and at a later stage, be the basis for a
-client side scripting engine.
-
-To compile this, you will need Enlightenment Foundation Libraries (EFL)
-installed in either /opt/e17 or /usr. These are typical places it get's
-installed in. You will also need flex. The rest of the dependencies
-are in the ../libraries directory.
-
-
-Design.
--------
-
-The basic design will be made up as I go along, but so far I have this -
-
-A parser parses an LSL script, validating it and reporting errors.
-
-A translator takes the result of the parse, and converts it into Lua
-source. Each LSL script becomes a Lua state. LSL states are handled as
-Lua tables, with each LSL state function being a table function in a
-common metatable. LL and OS functions are likely to be C or Lua
-functions. Careful testing should be done with LuaJIT FFI, sandboxing,
-and performance testing.
-
-The Lua source is compiled by the Lua compiler.
-
-LuaJIT is used as the Lua compiler, library, and runtime.
-
-Luaproc is used to start up operating system threads and hand Lua states
-between them. Luaproc messaging is also being used, but might need to
-change to edje messaging. Note - luaproc has been extensively rewritten
-for this project, mostly converting it to use EFL. That rewrite
-substantially shrunk the source code. Then it was all rewritten again
-to use EFL threads, and cooperative multitasking.
-
-THIS IS WHERE WE ARE RIGHT NOW.
-
-Should implement embedded Lua somehow. Probably the best thing to do is
-to have comments like -
-
-//Lua: local t = {1, 3, 42, x='something', 'something else}
-/*Lua: print(t.x) */
-
-The LSL parser picks these up and stores them in the AST as Lua
-snippets, then the compiler output functions just inserts them in the
-Lua code it is generating. Obviously these Lua snippets can access the
-rest of the generated Lua code. They should also be able to access
-skang and thus do proper GUI stuff on viewers that support skang.
-
-Nails will be used to pump commands in and out of the LuaSL system.
-Incoming commands invoke LSL events via the LuaSL state metatable. LL
-and OS functions that impact the world will be converted to nails
-commands sent to the command pump.
-
-Initially, since this is the first thing being written, a nails command
-pump client needs to be installed into OpenSim's C# stuff. Though it
-might be possible to talk directly to ROBUST instead. Think I'll try
-the ROBUST route, see how far I can get. That's the general principle
-applying in all of this - try to avoid C# and see how for we can get.
-lol
-
-On the other hand, might be better to leverage the existing C#
-implementations of LSL functions, just to get things up and running
-quickly. To that end, a protocol involving exchanging snippets of Lua
-over a network socket has been developed, and the next step is to write
-the C# side. sigh
-
-A watchdog thread should be used to make sure no LuaSL script spends
-forever processing any event.
-
-Some form of serialization will need to be created for saving script
-state during shutdowns, passing script state to other threads /
-processes / computers. Apparently Lua is good at this.
-
-There will have to be a MySQL (and maybe SQLite) client in the system,
-so we can talk directly to the local sim database. Esskyuehl may be
-suitable, though it's still in the prototype stage.
-
-Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST
-client will be needed to. Azy might be suitable, but it's also in
-prototype.
-
-An object is a file system directory, full of LSL scripts as text files,
-notecards as text files, animations as BVH (or later BVJ) files, etc.
-There will be some sort of metadata in place. This could be created by
-our own OpenSim compatible cache module.
-
-
-Test harness.
--------------
-
-I'll build a test harness. It will be based on EFL Edje Lua, with
-buttons for triggering LSL events, SL style dialogs, and other goodies.
-
-The initial goal will be to run standard MLP scripts. They have minimal
-interface to the world, and exercise quite a bit of the rest of LSL.
-They are also quite common, and sometimes responsible for a lot of the
-script running load.
-
-Later I should add stock standard OpenCollar scripts from SL. They are
-a bitch to get working under OpenSim, so would be good compatability
-tests.
-
-Various eina logging domains might be used to handle whisper, say, shout,
-etc.
-
-Performance testing will have to be done on 5000 scripts, to see how
-that compares against XEngine.
-
-The test harness became the love world server.
-
-
-TODO
-----
-
-Useful for limiting the amount of time scripts use -
-https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE
-http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly
diff --git a/docs/README.REST b/docs/README.REST
deleted file mode 100644
index 0d773f8..0000000
--- a/docs/README.REST
+++ /dev/null
@@ -1,2 +0,0 @@
-REST is probably good to apply to the web server part. Alice wants JSON
-to, but see nails.
diff --git a/docs/README.WTF b/docs/README.WTF
deleted file mode 100644
index 0bcf48f..0000000
--- a/docs/README.WTF
+++ /dev/null
@@ -1,5 +0,0 @@
-Refer to - OMG-WTF-BBQ.html
-
-This is where we deal with systems to keep track of where in the web
-assets are, and to cache them.
-
diff --git a/docs/README.libraries b/docs/README.libraries
deleted file mode 100644
index 8b99b7f..0000000
--- a/docs/README.libraries
+++ /dev/null
@@ -1,34 +0,0 @@
-There are some base libraries that should be used in common. Notable
-the Enlightenment Foundation Libraries (EFL), Irrlicht, lemon, LuaJIT,
-and luaproc. Other external open source projects that we just use
-directly should go here to. Makes it easy to compile it all.
-
-Note that in some cases, there might be changes. Such changes should be
-documented, and marked with "// onefang changes".
-
-EFL has been released, so not including that anymore. You can find it
-in distro repos, PPA's, etc. Or http://enlightenment.org/
-
-Irrlicht has been slightly modified to get it to use externally created
-GL stuff, and not use their internal copies of bzip, jpeglib, libpng,
-and zlib.
-
-Lemon is from http://www.hwaci.com/sw/lemon/.
-
-LuaJIT 2.0 has been released for Ubuntu 13.04 and later, try using
-https://launchpad.net/~mwild1/+archive/ppa for 12.04. Not including
-that anymore.
-
-luaproc has been hacked up a bit, and will continue to be hacked up.
-Merged it into LuaSL, so it's no longer here. Then replaced it
-completely.
-
---------------------------------------------------------------------
-
-These are the libraries written for the SledjHamr project.
-
-libLumbrJack is a library of logging stuff, coz every one wants to log.
-
-libRunnr is for running Lua scripts. Named (sorta) after a friend of mine.
-
-libSledjHamr is a motley collection of stuff that is needed.
diff --git a/docs/README.nails b/docs/README.nails
deleted file mode 100644
index 7512944..0000000
--- a/docs/README.nails
+++ /dev/null
@@ -1,14 +0,0 @@
-Refer to - Nails.html
-
-Nails bangs it all together, mostly via the command pump.
-
-
-Not sure where else to put this, but nails I think is the bit that
-drives the network traffic the most -
-
-http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
-
-
-Another article that deals with network issues in a 3D networked game -
-
-http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?print=1
diff --git a/docs/SledjHamr/README.Bookie b/docs/SledjHamr/README.Bookie
new file mode 100644
index 0000000..bec4b19
--- /dev/null
+++ b/docs/SledjHamr/README.Bookie
@@ -0,0 +1,33 @@
+Shared dynamic libraries is a bit of an issue for cross platform code.
+LL viewers deal with it by including their own copies of the libraries
+they use. This bypasses the idea of sharing them, and thus uses too
+much resources. On the other hand, it seems to be the Windows way of
+doing things, lots of Windows packages I have seen include their own
+copies of libraries. Mac Os X seems to do the same, each application is
+installed as it's own directory, filled with it's own copies of
+libraries. Not a lot of sharing going on. Linux and the BSDs do the
+right thing, most libraries are actually shared. Except that LL viewers
+STILL bring their own libraries.
+
+I think the main difference is having a proper package management
+system. Apt, RPM, and portage (I think) can track dependencies on
+libraries, install the libraries automatically, and even have different
+versions of libraries installed side by side. Without this, the OS has
+no official way of tracking library dependencies, so every one has to
+supply their own. Sure Mac OS X has had a few package systems ported to
+it, but none of them are the official one, so developers can't rely on
+them.
+
+SledjHamr has to deal with this, and try to do so in some sort of smart
+way. As usual, the right way to do things is generally to do the
+opposite of what LL does. lol
+
+Bookie should be a sub system that probes the OS, trying to see if
+there's some sort of OS store of libraries, and try to find reasonable
+versions of the libraries needed in that. If not found, it could invoke
+an OS specific method of installing a suitable library. If that fails,
+it can download a SledjHamr specific version into the SledjHamr
+installed directory. So it tries to do the right thing first, and
+gradually falls back to doing the wrong thing like LL does.
+
+That's the theory, in practice, gonna be a pain.
diff --git a/docs/SledjHamr/README.HamrSpace b/docs/SledjHamr/README.HamrSpace
new file mode 100644
index 0000000..a2e19cf
--- /dev/null
+++ b/docs/SledjHamr/README.HamrSpace
@@ -0,0 +1 @@
+Inventory server.
diff --git a/docs/SledjHamr/README.Lspace b/docs/SledjHamr/README.Lspace
new file mode 100644
index 0000000..2eb9b24
--- /dev/null
+++ b/docs/SledjHamr/README.Lspace
@@ -0,0 +1,3 @@
+Sim contents server, which is pretty much a web server. Should support
+WebDAV so people can point their file browsers at it. More details in
+love.txt.
diff --git a/docs/SledjHamr/README.LuaSL b/docs/SledjHamr/README.LuaSL
new file mode 100644
index 0000000..7556bf7
--- /dev/null
+++ b/docs/SledjHamr/README.LuaSL
@@ -0,0 +1,121 @@
+Refer to - LuaSL_New_scripting_engine.html
+
+LuaSL is a Lua based LSL scripting engine that will aim for LSL
+compatibility first, then adding Lua extensions. It aims to replace the
+woeful XEngine from OpenSim, and at a later stage, be the basis for a
+client side scripting engine.
+
+To compile this, you will need Enlightenment Foundation Libraries (EFL)
+installed in either /opt/e17 or /usr. These are typical places it get's
+installed in. You will also need flex. The rest of the dependencies
+are in the ../libraries directory.
+
+
+Design.
+-------
+
+The basic design will be made up as I go along, but so far I have this -
+
+A parser parses an LSL script, validating it and reporting errors.
+
+A translator takes the result of the parse, and converts it into Lua
+source. Each LSL script becomes a Lua state. LSL states are handled as
+Lua tables, with each LSL state function being a table function in a
+common metatable. LL and OS functions are likely to be C or Lua
+functions. Careful testing should be done with LuaJIT FFI, sandboxing,
+and performance testing.
+
+The Lua source is compiled by the Lua compiler.
+
+LuaJIT is used as the Lua compiler, library, and runtime.
+
+Luaproc is used to start up operating system threads and hand Lua states
+between them. Luaproc messaging is also being used, but might need to
+change to edje messaging. Note - luaproc has been extensively rewritten
+for this project, mostly converting it to use EFL. That rewrite
+substantially shrunk the source code. Then it was all rewritten again
+to use EFL threads, and cooperative multitasking.
+
+THIS IS WHERE WE ARE RIGHT NOW.
+
+Should implement embedded Lua somehow. Probably the best thing to do is
+to have comments like -
+
+//Lua: local t = {1, 3, 42, x='something', 'something else}
+/*Lua: print(t.x) */
+
+The LSL parser picks these up and stores them in the AST as Lua
+snippets, then the compiler output functions just inserts them in the
+Lua code it is generating. Obviously these Lua snippets can access the
+rest of the generated Lua code. They should also be able to access
+skang and thus do proper GUI stuff on viewers that support skang.
+
+Nails will be used to pump commands in and out of the LuaSL system.
+Incoming commands invoke LSL events via the LuaSL state metatable. LL
+and OS functions that impact the world will be converted to nails
+commands sent to the command pump.
+
+Initially, since this is the first thing being written, a nails command
+pump client needs to be installed into OpenSim's C# stuff. Though it
+might be possible to talk directly to ROBUST instead. Think I'll try
+the ROBUST route, see how far I can get. That's the general principle
+applying in all of this - try to avoid C# and see how for we can get.
+lol
+
+On the other hand, might be better to leverage the existing C#
+implementations of LSL functions, just to get things up and running
+quickly. To that end, a protocol involving exchanging snippets of Lua
+over a network socket has been developed, and the next step is to write
+the C# side. sigh
+
+A watchdog thread should be used to make sure no LuaSL script spends
+forever processing any event.
+
+Some form of serialization will need to be created for saving script
+state during shutdowns, passing script state to other threads /
+processes / computers. Apparently Lua is good at this.
+
+There will have to be a MySQL (and maybe SQLite) client in the system,
+so we can talk directly to the local sim database. Esskyuehl may be
+suitable, though it's still in the prototype stage.
+
+Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST
+client will be needed to. Azy might be suitable, but it's also in
+prototype.
+
+An object is a file system directory, full of LSL scripts as text files,
+notecards as text files, animations as BVH (or later BVJ) files, etc.
+There will be some sort of metadata in place. This could be created by
+our own OpenSim compatible cache module.
+
+
+Test harness.
+-------------
+
+I'll build a test harness. It will be based on EFL Edje Lua, with
+buttons for triggering LSL events, SL style dialogs, and other goodies.
+
+The initial goal will be to run standard MLP scripts. They have minimal
+interface to the world, and exercise quite a bit of the rest of LSL.
+They are also quite common, and sometimes responsible for a lot of the
+script running load.
+
+Later I should add stock standard OpenCollar scripts from SL. They are
+a bitch to get working under OpenSim, so would be good compatability
+tests.
+
+Various eina logging domains might be used to handle whisper, say, shout,
+etc.
+
+Performance testing will have to be done on 5000 scripts, to see how
+that compares against XEngine.
+
+The test harness became the love world server.
+
+
+TODO
+----
+
+Useful for limiting the amount of time scripts use -
+https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE
+http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly
diff --git a/docs/SledjHamr/README.REST b/docs/SledjHamr/README.REST
new file mode 100644
index 0000000..0d773f8
--- /dev/null
+++ b/docs/SledjHamr/README.REST
@@ -0,0 +1,2 @@
+REST is probably good to apply to the web server part. Alice wants JSON
+to, but see nails.
diff --git a/docs/SledjHamr/README.WTF b/docs/SledjHamr/README.WTF
new file mode 100644
index 0000000..0bcf48f
--- /dev/null
+++ b/docs/SledjHamr/README.WTF
@@ -0,0 +1,5 @@
+Refer to - OMG-WTF-BBQ.html
+
+This is where we deal with systems to keep track of where in the web
+assets are, and to cache them.
+
diff --git a/docs/SledjHamr/README.libraries b/docs/SledjHamr/README.libraries
new file mode 100644
index 0000000..8b99b7f
--- /dev/null
+++ b/docs/SledjHamr/README.libraries
@@ -0,0 +1,34 @@
+There are some base libraries that should be used in common. Notable
+the Enlightenment Foundation Libraries (EFL), Irrlicht, lemon, LuaJIT,
+and luaproc. Other external open source projects that we just use
+directly should go here to. Makes it easy to compile it all.
+
+Note that in some cases, there might be changes. Such changes should be
+documented, and marked with "// onefang changes".
+
+EFL has been released, so not including that anymore. You can find it
+in distro repos, PPA's, etc. Or http://enlightenment.org/
+
+Irrlicht has been slightly modified to get it to use externally created
+GL stuff, and not use their internal copies of bzip, jpeglib, libpng,
+and zlib.
+
+Lemon is from http://www.hwaci.com/sw/lemon/.
+
+LuaJIT 2.0 has been released for Ubuntu 13.04 and later, try using
+https://launchpad.net/~mwild1/+archive/ppa for 12.04. Not including
+that anymore.
+
+luaproc has been hacked up a bit, and will continue to be hacked up.
+Merged it into LuaSL, so it's no longer here. Then replaced it
+completely.
+
+--------------------------------------------------------------------
+
+These are the libraries written for the SledjHamr project.
+
+libLumbrJack is a library of logging stuff, coz every one wants to log.
+
+libRunnr is for running Lua scripts. Named (sorta) after a friend of mine.
+
+libSledjHamr is a motley collection of stuff that is needed.
diff --git a/docs/SledjHamr/README.nails b/docs/SledjHamr/README.nails
new file mode 100644
index 0000000..7512944
--- /dev/null
+++ b/docs/SledjHamr/README.nails
@@ -0,0 +1,14 @@
+Refer to - Nails.html
+
+Nails bangs it all together, mostly via the command pump.
+
+
+Not sure where else to put this, but nails I think is the bit that
+drives the network traffic the most -
+
+http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
+
+
+Another article that deals with network issues in a 3D networked game -
+
+http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?print=1
diff --git a/docs/SledjHamr/The_Naminator.txt b/docs/SledjHamr/The_Naminator.txt
new file mode 100644
index 0000000..8a6a25e
--- /dev/null
+++ b/docs/SledjHamr/The_Naminator.txt
@@ -0,0 +1,14 @@
+The Naminator eliminates human readable names, to make way for computer
+names for SkyNet. Or something.
+
+In world names can be anything, but they map more or less to file names
+and URLs, so the names have to be munged accordingly. A further issue
+is that different in world objects can have the same name. Lots of
+copies of the same thing, or two different things that happen to be
+called the same thing. No one is gonna individually name each tree in a
+forest, or every lamppost in the city. File names and URLs have to be
+unique. The Naminator deals with munging names to deal with these
+issues. It should generate names that are compatible with a variety of
+operating and file systems, as well as being URL compatible. This is
+such a useful thing to do that it should be a shared library, even if it
+will be tiny.
diff --git a/docs/SledjHamr/love.txt b/docs/SledjHamr/love.txt
new file mode 100644
index 0000000..e262ef2
--- /dev/null
+++ b/docs/SledjHamr/love.txt
@@ -0,0 +1,271 @@
+Love makes the world go around. Though in this case, it's the name of
+the world server, the module that directly controls what happens to the
+content of the virtual world.
+
+The love world server that deals with changing the world. It manages
+the on disk representation of the world, and lets others screw with it
+via nails pumps. Love also sends nails events on changes.
+
+World server vs local world.
+----------------------------
+
+Extantz defaults to running a local world at start up. Lspace serves
+the content for a networked world. They may be the same world if the
+local world is also networked. Nails pumps commands to and from the
+world.
+
+Lspace just serves the results as a web server. The love world server
+changes on disk content, Lspace checks on disk modified time stamps to
+deal with "do you have a newer version" HTTP requests. Standard web
+server stuff really, though a mod_nails might be useful to catch events
+in order to invalidate any internal web caches.
+
+For networked worlds, Extantz fetches new content from Lspace, and hooks
+up to the nails pump of the love server for changes. For local worlds,
+extantz would basically BE the world server? No, that duplicates
+things, it can just run a local love server, then connect to it like
+every one else. No need to connect to a local Lspace server, just deal
+with the file system direct.
+
+The local love server would be configured to listen on 127.0.0.1, and/or
+the outside IP address. Extantz checks to see if there's one running on
+127.0.0.1 first before starting one if needed.
+
+Separate vs combined.
+---------------------
+
+There's two ways of doing this. The world server could be part of
+Lspace, or they could be separate modules. What we really have is a web
+server, backing store, and command pump. The command pump is nails, and
+should be a library that is shared, since both ends of the protocol
+would be needed by most modules.
+
+Combined might be useful to conserve resources. They both need to deal
+with the contents of the world. Lspace just serves it to the outside
+world via HTTP, but needs to track changes. Love makes those changes,
+and also sends changes via nails to every one. Keeping the current
+working set in memory only once saves a lot of memory.
+
+The down sides of combined is that one might bog down the other, and it
+gets harder to use standard web servers.
+
+Separated is good coz Lspace might just be any ordinary web server.
+They already have mechanisms in place to serve dynamic data, and even
+deal with changes to the files. This is the whole point of basing the
+major asset shifting part of the protocol on the web, people can use all
+the major amounts of web infrastructure that already exists and already
+solves most of the problems that currently plague virtual worlds based
+on SL tech.
+
+The down side of separated is that changes might be slower propagating
+to the web server, and there might be two copies of any given set of
+assets in memory at once.
+
+A third option is to be separated, but any given web server could have a
+mod_love type module written for it. This could share memory with the
+love server process. So tighter integration is an option, but they can
+work apart. Changes happen in this shared memory, driven by the command
+pump in the love server. Lspace just needs read access, and just
+serves the current state of the world. Love server persists to disk
+when it's ready to, though the shared memory can just be memory mapped
+files. This is the best of both worlds, excuse the pun.
+
+
+Thoughts about directory structure.
+========================================
+
+A major goal is to have the disk structure of a sim (and inventory) be
+decently human readable. The assets should be stored as normal files of
+the appropriate type, so that they can be edited with normal editing
+software like blender, gimp, a text editor, etc. Other goals include
+not duplicating assets, and making it easy to move assets around.
+
+Names.
+------
+
+A major LL created problem is that in world objects can have the same
+name, though stuff in an objects inventory is forced to have unique
+names by automatically adding numbers to the names. In inventory you
+can have stuff with the same name to. The same named objects don't have
+to be the same object, they can be completely different. A simple
+object name to file name matching, with directories for contents, just
+wont work. Need to munge the names anyway.
+
+All name munging should produce names that are compatible with various
+OS file systems, compatible with URLs, add "_123" numbers at the end for
+duplicate names in the same directory, and auto add a file extension if
+one is missing. Probably should check the file type if there IS a file
+extension.
+
+Links and URLs.
+---------------
+
+Any asset file could be a stuffs.lnk file, which holds a relative path
+name or full URL pointing to the real asset. An external lspace server
+would return the .omg file when the stuffs URL is requested, or an
+actual asset file when those are requested.
+
+Would have to do copy on write for editing and other state changes, not
+including script state changes.
+
+Probably need to store other info in the .lnk file if it's a URL, SHA-1
+of the original file, other web cache info. Which starts to encroach on
+web proxy / cache territory, which we may not want to do, since we want
+to use real ones instead of crappy LL cache.
+
+Actually, file names / URLs in .omg files would mostly be relative to
+the file name / URL of the sim, and all the way down, so relative to the
+directory things are in. It's up to the client to keep track of where
+they are and build appropriate full URL / full path file names.
+
+UUIDS.
+------
+
+Original LL UUIDs are the usual 36 byte string representing 32 lower
+case hex characters and some dashes, encoding a 128 bit number. I was
+inspired by git using SHA-1 hashes for content addressable assets.
+SHA-1 hashes are 40 character hex codes representing 160 bit numbers
+that are calculated based on the content. So the same content will give
+the same SHA-1 hash. Git has proved that you only need the first digits
+of the SHA-1 hash to ensure uniqueness, so it's feasible to use only the
+first 128 bits of SHA-1 hashes to squeeze it into a UUID for the
+purposes of uniquely identifying assets. Precisely what git does. This
+means it could be backwards compatible with LL's use of UUIDs.
+
+Since the SHA-1 code of identical files is the same, we could use this
+to reduce duplicated large assets that never change, like textures and
+sounds. This will be a big win.
+
+I think we can get away with not storing SHA-1 hashes permanently, just
+use them for in memory references, but cache them to disk separately.
+The caches can be recreated at any time, since the SHA-1 hashes can be
+calculated based on the data in the assets. So no UUIDs stored in .omg
+files, just relative file / URL friendly names. The UUID / SHA-1 hashes
+are mostly for keeping in memory as keys to stuff, coz they can shrink
+down to a long long 128 bit integer.
+
+Each asset file, whether texture, script, mesh, text file, etc, comes
+with a matching .sha1 file that holds the SHA-1 hash of that file. .lnk
+files get hashed to, so that each copy of a linked stuffs gets it's own
+SHA-1 hash, but in this case the "content" is the relative path name.
+The .sha1 files of the real asset .lnk files point to can be found in
+the same place the real asset file is. Hmm, this means that reference
+counting will be needed, otherwise the one real copy of an asset can get
+deleted while links still point to it.
+
+There will be a .sha1 directory full of files with the SHA-1 hashes as
+part of the name, and the rest being similar to a .lnk file, a path to
+the asset or .lnk file. Would save love server needing to keep that all
+in memory all the time.
+
+If the file system date stamp for the asset file is later than the one
+for the .sha1 file, then someone edited the file, recreate the .sha1
+files.
+
+All the SHA-1 hashes can be recreated at any time, using file system
+date stamps to tell if one is stale. They are only used internally to a
+running system, to pass small identifiers around, and to fake LL UUIDs
+for LSL scripts. When a SHA-1 hash is calculated for a new asset, it
+gets stored in the .sha1, but if it already exists in .sha1, then the
+asset is replaced by that sha1.lnk file, thus automatically
+deduplicating assets.
+
+Reference counting.
+-------------------
+
+Dunno yet, just realised the need for this, will come up with something
+soon. Will solve this problem when we implement links, wont need it
+until then anyway.
+
+Obviously the count has to be kept with the real asset file, there's a
+few ways to go about that. I've been thinking that the .sha1 file might
+be a good place to keep other meta data, like perhaps owner and group
+info. So one way is to include the reference count there to. Another
+option is a separate .ref file with the count inside. A third option,
+just tack the count onto the end of a file name. This is likely a bit
+quicker than updating a file.
+
+On disk structure.
+------------------
+
+"some sim name" -> some%20sim%20name/index.omg
+ list of stuffs rezzed in the sim
+ stuffs position, size, and orientation
+ relative file / URL name pointing to the stuffs
+ no need for the in world name, those interested in that will likely grab the stuffs.omg file anyway
+
+ "a stuffs" -> a%20stuffs.omg
+ in world name, description
+ list of stuffs similar to the sim index.omg, only this is for the various meshes that make up this stuffs.
+ stuffs position, size, and orientation, relative to this stuffs
+ relative file / URL name pointing to the mesh and textures
+ extra info for each material
+
+ a%20stuffs/ directory
+ files that are the contents of this stuffs
+ could be .lnk files
+ .sha1 files
+
+ a%20stuffs/index.omg
+ used to be a list of content file names, type, and UUID
+ file names are right there in the directory
+ UUID ala SHA-1 can now be calculated based on those files
+ and stored in an asset.sha1 file
+ type can use the magic/file/MIME system to identify file types
+ can get rid of this file, though maybe have it in a .types directory,
+ coz we would want to cache the file type
+ or just use a poor mans magic/file/MIME thingy based on file extension,
+ since we only have a small number of file types
+ note cards should have a .txt, scripts a .lsl or .lua
+
+People could even be free to use their own organising directory
+structure. A directory for ground level, and one for each sky box for
+instance. Relative paths inside .omg files sorts that all out.
+
+A sims index.omg file might be constantly updated for busy sims. Could
+generate it on the fly by the Lspace server, based on the actual
+contents of the sim directory. Alternative Lspace servers could just
+use a CMS system for all of this anyway. They would still use the same
+structure for URLs and .omg files.
+
+Avatars.
+--------
+
+Storing avatars in this way isn't such a good idea? Avatars could have
+their own avatar.omg dealing with shape, skin, clothes, attachments,
+etc. But instead of a client asking for a list, avatar arrivals and
+departures are driven by love. Though try to keep avatars as "just
+ordinary object, but with a person controlling it". Still, they move
+around a lot.
+
+Avatar.omg would live on the users hard drive, but sent to the love
+server on login, and after any change.
+
+Misc.
+-----
+
+Right now I'm using Lua style .omg files, but eet would be a better
+choice I think. Saves having to write a Lua table to C structure
+system, which eet already has, sorta. Lua tables are at least more
+readable while I consider the design, but likely use eet instead when I
+have to write code to read the suckers. .omg files are managed by the
+love server, so fiddling with them is an expert thing anyway.
+
+Should have a tool to validate a sims files and recreate the caches.
+
+Remaining issues.
+-----------------
+
+Owner / group UUID might be better dealt with elsewhere? Coz links.
+Also, we wont replicate the LL user / group stuff exactly, but morph
+into more standardised variations. Jabber users, jabber group rosters,
+OS users, LDAP users and groups, web site users, etc. So just provide
+an abstraction, and an example or two.
+
+ might be better to move compiled scripts and generated Lua source to the LuaSL server's own private store?
+ LuaSL needs to assign UUIDs to compiled script binaries, so it knows which running script is which
+ coz there might be lots of copies of scripts
+ on the other hand, each copy is uniquely named inside some objects contents,
+ even if it's a link,
+ so the UUID of the stuffs plus the UUID within the stuffs contents, for this copy / link of the script should suffice?
+
diff --git a/docs/SledjHamr/no_accounts.txt b/docs/SledjHamr/no_accounts.txt
new file mode 100644
index 0000000..5ecbe08
--- /dev/null
+++ b/docs/SledjHamr/no_accounts.txt
@@ -0,0 +1,29 @@
+We don need no stinkin' accounts.
+
+We don't really need accounts, so we can do away with them. Though
+obviously since SledjHamr is designed to be a flexible set of tools
+rather than one big take it or leave it system, people can use what ever
+accounts system they need for their purposes. SledjHamr not only doesn't
+impose an accounts system, we eliminate the need for one in the general
+case. So we don't have to write one. B-)
+
+When a user fires up the extantz client for the first time, it can use
+their local computer account name as the users name (I think most
+operating systems make you create one when you install them). Extantz
+could also do a reverse DNS lookup on the computers IP, and likely end
+up with an ISPs dynamic IP reverse mapping, or maybe a real domain name.
+
+Extantz then tries to connect to a love server running on the same
+computer, or starts one if it can't find one. This local love server by
+default runs a small grid, with maybe a nice little cottage, and a star
+gate. This is the users home, they can do what ever they like with it.
+
+The star gate works similar to current OpenSim hypergates, linking to
+external grids and allowing HyperGrid access to them. Since the user
+already has a local name and domain name, with the local love server
+acting as the users home HyperGrid server, they are good to go visit
+other grids. No real in world account need ever be created.
+
+The drawback is that the virtual worlds will be filled with lots of
+root@123_231.bigisp-dyn.com users. Naturally it should be simple for
+users to change the default name to anything they want.
diff --git a/docs/SledjHamr/portals.txt b/docs/SledjHamr/portals.txt
new file mode 100644
index 0000000..591460b
--- /dev/null
+++ b/docs/SledjHamr/portals.txt
@@ -0,0 +1,106 @@
+SledjHamrs killer feature, or one of them.
+
+A major reason for SledjHamr is to break down the garden walls. We do
+this by allowing free travel between peoples virtual worlds. In OpenSim
+this is done by HyperGrid, which is clunky and hard to use. Second Life
+deliberately has no such system. Even worse, it's hard convincing people
+in SL to visit your grid, coz it's all very hard, again due to
+deliberate policy decisions by LL. LL knows their content is the key to
+their business, even though almost all of it was created by the users,
+LL locks it up tight. So people visiting OpenSim grids from SL have to
+create a new avatar from scratch, which is such a major pain that most
+people balk at that and don't bother. And they can't bring their
+inventory with them, inventory they paid for and spent years collecting.
+
+In SledjHamr, as well as allowing completely unrestricted and easy
+access to lots of content, we should make it easy to travel between
+virtual worlds. Part of this is to include compatibility layers in
+separate modules to be compatible with what ever virtual world systems
+are around. You would still need to create accounts and log onto those
+worlds though. How can we mix them up? I imagine easy to use portal
+objects. Let's start with the basics, and work out some more complex
+examples.
+
+As mentioned in the no_accounts.txt document, every SledjHamr user has
+their own little world running on their computer by default when they
+start up the extantz client. There is a star gate on this default
+world, an already setup portal that can connect to a bunch of default
+external worlds. The user can use this star gate, and other peoples
+portals to travel around other peoples worlds. Initially this could be
+using OpenSim and its HyperGrid system. Later it would be SledjHamr
+style worlds as well.
+
+A portal would be like Cobalt style portals, you can see the destination
+in real time, and step through it to go there. They can be permanent,
+or temporary. You can carry them in your inventory, they could just be
+normal scripted in world objects.
+
+So you travel around the virtual worlds, meeting people, and you want to
+invite some one to your home, or a group of people. You right click on
+them and select "Invite them home" from the menu. Extantz knows your
+home world, that's where you started and it's running on the same
+computer. Extantz communicates to that home server, or starts it up
+first. The home server adds this new person to it's access list.
+Extant creates a portal object and offers it to the person, so they can
+rez it anywhere. Or you could rez this portal object in the world you
+are in. Either way, once the portal is in a world, it connects to your
+home world, showing a view of your front gate, maybe including your
+lovely garden in your front yard. The portal connects to the "front
+gate" of your home world.
+
+Any one on your home worlds access list can step through this portal to
+get to your home world. Simple to use, no figuring out HyperGate URLs
+and copy pasting them, no manual messing with hard to use acces systems.
+Though it would still be possible to create URLs to in world places, to
+store as landmarks, to email to someone, or to copy'n'paste into
+farcebook.
+
+Portals rezzed in world could be temporary, and vanish after who ever
+you invited to come stepped through it. Or time out several minutes
+later so as not to clutter the universe with left over portals. Or
+deleted by the owner / managers of the world you left them, or deleted
+yourself from your own world. Portals could be permanent. Say you
+found a larger world that you and the owner decide you wish to be a part
+of. Portals could be left on both worlds linking them. The "portal"
+could just be reconfiguring each world to locate the other world near
+them, like neighbouring sims. Still, that should be done via the portal
+interface, just a simple click.
+
+Portals can be fully open if you want to run a public world. People can
+be banned. Or private worlds with specific groups and people allowed.
+Similar to many web sites, you could have your own account system on
+your world, people with accounts are allowed to build, or allowed to
+with certain limits, or are the only ones allowed to visit. Privacy can
+be applied to the portal, only those that can step through can see
+through, or semi private, you can see a limited area, but not step
+through. A portal could include a "door bell", people that want to
+visit ring the door bell, someone might answer and let them in, but can
+chat with them across the portal first. Perhaps getting dressed first.
+
+For those hard to reach places, I'm looking at you SL, a portal could be
+coded as an LSL script in a SL prim object that you keep in your SL
+inventory. It can operate in two modes, depending on who is looking.
+If someone using a SledjHamr aware client looks, they see the usual
+portal view mentioned above, and can easily step through it as usual.
+Others would see a still photo of the view through the portal, or
+perhaps a live video stream if the other world server has enough
+bandwidth to support that. Or they could see just a logo if the world
+owner hasn't bothered to pay LL to upload a suitable photo. If the user
+of the viewer that is not SledjHamr aware clicks on or tries to step
+through the portal, they are sent to a web page that lets them download
+SledjHamr aware clients, with instructions on what to do to actually get
+to that world.
+
+Once a user of that closed world steps through the portal using a
+SledjHamr aware client, their client knows what that person looks like,
+and has access to that persons inventory in that closed world, so they
+can bring it all with them with no need to do anything other than step
+through. The user remains logged on to the closed world, coz SledjHamr
+needs no actual accounts. What their avatar is left doing in the closed
+world for others to see is an open question. Perhaps sitting on some
+chair on the portal prims, snoozing. Just had a better idea, the user
+gets a new tab, in their original world they can wander off again and do
+stuff, and in the new world they can do new stuff. Likely LL will ban
+this in their TOS, and ban SLedjHamr aware viewers, they are anal like
+that, and want to own your content to keep people locked in their walled
+garden. Here's a SledjHamr for you all, break those walls open. B-)
diff --git a/docs/SledjHamr/privacy.txt b/docs/SledjHamr/privacy.txt
new file mode 100644
index 0000000..992867b
--- /dev/null
+++ b/docs/SledjHamr/privacy.txt
@@ -0,0 +1,5 @@
+There is more to come on this subject, but I just want to make a quick
+note about stuff a friend just brought up.
+
+For people that share their computers, should have master passwords for
+each user, and encrypt accounts, logs, log out photos, settings, etc.
diff --git a/docs/The_Naminator.txt b/docs/The_Naminator.txt
deleted file mode 100644
index 8a6a25e..0000000
--- a/docs/The_Naminator.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-The Naminator eliminates human readable names, to make way for computer
-names for SkyNet. Or something.
-
-In world names can be anything, but they map more or less to file names
-and URLs, so the names have to be munged accordingly. A further issue
-is that different in world objects can have the same name. Lots of
-copies of the same thing, or two different things that happen to be
-called the same thing. No one is gonna individually name each tree in a
-forest, or every lamppost in the city. File names and URLs have to be
-unique. The Naminator deals with munging names to deal with these
-issues. It should generate names that are compatible with a variety of
-operating and file systems, as well as being URL compatible. This is
-such a useful thing to do that it should be a shared library, even if it
-will be tiny.
diff --git a/docs/index.html b/docs/index.html
index 2687d1d..73fc1a3 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -28,6 +28,6 @@ Welcome to the SledjHamr home!
BlackListAssetServersTracker Might be cool if you could accept/reject asset servers. For copyright control or to avoid seeing yucky stuff.
We have a code repo on github now - https://github.com/onefang/SledjHamr with just a small README that points to this page. We can finally start writing code. A local copy of the source can be found here.
-Now that we have a web site, I should turn this into a real web site, huh?
+Now that we have a web site, I should turn this into a real web site, huh? Some of the docs are in raw text format, SledjHamr docs and ClientHamr docs