21 files changed, 27 insertions, 27 deletions
diff --git a/docs/BVJ.html b/docs/ClientHamr/BVJ.html
index a539705..d01f234 100644
--- a/docs/BVJ.html
+++ b/docs/ClientHamr/BVJ.html
@@ -158,7 +158,7 @@ implement animating link sets, and interaction with the sim physics.</p>
 <p>There are use cases where it makes good sense to communicate an animation between clients with almost no server interaction. Why pay 10 Bogus-Bucks to adjust the position of my hand as we sit next to each other. I'll just edit my avatar to move my hand and the client will make a BVJ file ship it to your client which will show it to you.</p>
 <p>&nbsp;</p>
 <h3> Changing Poses </h3>
-<p>Fang Said: See the very last paragraph of <a href="SledjHamr.html">SledjHamr</a>, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.</p>
+<p>Fang Said: See the very last paragraph of <a href="../SledjHamr.html">SledjHamr</a>, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.</p>
 <p>Alice Replied: Looks cool, but requires Inverse Kinematics (if you mean the touch commands), or some puppeteer protocol that I know nothing about.</p>
 <p>What I imagine right now is <a href="InworldAnimationEditor.html">InworldAnimationEditor</a></p>
 <h2>links</h2>
diff --git a/docs/ClientHamr.html b/docs/ClientHamr/ClientHamr.html
index 30228a3..f77279c 100644
--- a/docs/ClientHamr.html
+++ b/docs/ClientHamr/ClientHamr.html
@@ -3,7 +3,7 @@
 <head>
 </head>
 <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
-<p>Consider your inventory.  A mess huh.  Well, what is it really, especially in a world like <a href="NGIW.html">NGIW</a> / <a href="index.html">OMG</a> describes?  It's just yet another hierarchy of folders and thingies.  We are probably wasting our time writing any code for it.  Why not leverage the users favourite hierarchy browser/editor.  Maybe it's called FileDamager made by MicroCruft in Redstone Wishangton.  Maybe it's called Netscape, or Nautilus.  Many of the modern file browser tools will talk a protocol named WebDAV.  If the asset server spoke WebDAV, then we could perhaps rip the inventory code clean out of the client.</p>
+<p>Consider your inventory.  A mess huh.  Well, what is it really, especially in a world like <a href="../common/NGIW.html">NGIW</a> / <a href="../index.html">OMG</a> describes?  It's just yet another hierarchy of folders and thingies.  We are probably wasting our time writing any code for it.  Why not leverage the users favourite hierarchy browser/editor.  Maybe it's called FileDamager made by MicroCruft in Redstone Wishangton.  Maybe it's called Netscape, or Nautilus.  Many of the modern file browser tools will talk a protocol named WebDAV.  If the asset server spoke WebDAV, then we could perhaps rip the inventory code clean out of the client.</p>
 <p>This little fantasy points in a really blue sky direction.  Use existing protocols and tools to remove stuff from the client.  Make it easy for tools that already exist to interact with the 3d world.</p>
 <p>That's the Client Hammer.  ClientHamr is the concept that we can apply the unix philosophy to the viewer.  Use individual tools that are good at their job to split off bits of the big bad blob that is the viewer.  Using standard protocols and tools where we can.</p>
 <p>Note - The simian grid has a WebDav front end to inventory. <a href="http://code.google.com/p/openmetaverse/">http://code.google.com/p/openmetaverse/</a></p>
diff --git a/docs/InworldAnimationEditor.html b/docs/ClientHamr/InworldAnimationEditor.html
index 82da594..82da594 100644
--- a/docs/InworldAnimationEditor.html
+++ b/docs/ClientHamr/InworldAnimationEditor.html
diff --git a/docs/SledjHamr.html b/docs/SledjHamr.html
index b2371f1..304c884 100644
--- a/docs/SledjHamr.html
+++ b/docs/SledjHamr.html
@@ -8,7 +8,7 @@
 <p>This might sometimes be referred to as SledjHamr, SldjHmr, NGIW,or the term that currently has favour - Open Magic Garden (OMG).</p>
 <p>I'm a firm believer that we should use the existing SL based viewer code, and the existing OpenSim server code, as crutches. They are both crap really, but they have the benefit of actually working. The alternative is to throw it all out and start from scratch. A virtual world system is REALLY BIG, something a small team will take years to write, even if we did it full time. So that would be many years before we even have enough of a brand new system to have ruth standing still on an empty plane. By leveraging existing systems, we already have something people can use, we just make it better when we can. OpenSim at least is modular, so we can replace things one module at a time. For both server and viewer, we can chip away at existing code at our leisure, slowly turning insane code into sane code. Meta-impy is the fork I made of the Imprudence viewer, so that is the viewer I'm changing.</p>
 <p>BTW, my definition of "sane" code is - performance critical stuff should be in C, with perhaps some hand written assembler. A lot of the virtual world stuff is performance critical. Things should be written as small, and as flexible, as possible, so that many small things can work together in unintended ways to do cool stuff. The Enlightenment Foundation Libraries (which I have done some development for) are a good example. matrix-RAD was my 10 year experiment in pursuing some of these ideas, though it was in Java.</p>
-<p>See <a href="NGIW.html">NGIW</a> for more ideas from Alice. Interestingly enough, some of my ideas are basically the conclusion of one of the OpenSim developers Masters degree dissertation <a href="http://justincc.org/blog/2010/10/25/my-masters-dissertation-on-internet-scale-virtual-environment-architectures/">http://justincc.org/blog/2010/10/25/my-masters-dissertation-on-internet-scale-virtual-environment-architectures/</a> . Note, I read that after I came up with these ideas.</p>
+<p>See <a href="common/NGIW.html">NGIW</a> for more ideas from Alice. Interestingly enough, some of my ideas are basically the conclusion of one of the OpenSim developers Masters degree dissertation <a href="http://justincc.org/blog/2010/10/25/my-masters-dissertation-on-internet-scale-virtual-environment-architectures/">http://justincc.org/blog/2010/10/25/my-masters-dissertation-on-internet-scale-virtual-environment-architectures/</a> . Note, I read that after I came up with these ideas.</p>
 <p>&nbsp;</p>
 <h2> boxen </h2>
 <p>We can have servers that just store and forward the sim data. Clients edit that data, if they are allowed to. Special servers (engines) can do the physics and server side script running, they act as clients to the sim data server. No reason why this can't all be on the same computer, or separate ones.</p>
diff --git a/docs/Grid-data-flow.html b/docs/SledjHamr/Grid-data-flow.html
index 1f3ff93..1a91726 100644
--- a/docs/Grid-data-flow.html
+++ b/docs/SledjHamr/Grid-data-flow.html
@@ -16,7 +16,7 @@
 <p>Sim servers point to one or more ROBUST servers for their services, These pointers are a HTTP URLs that is usually the grid server, and a port number. You can have different ROBUST services on different port numbers, or on different servers. The ROBUST servers can handle one or more of the services. ROBUST servers can point to others, acting as a proxy. ROBUST hosted services can have others as dependencies, they can point to other instances of ROBUST on other URL/ports.</p>
 <p>Robust has the concept of IN and OUT connectors. The IN's seem to be the ports used by sim servers and others to connect to the services, they load the proper OUT or code modules. The OUTS seem to be the connectors to the database, or perhaps the code performing the service. Or maybe the OUTs are for sending data back, and the modules are for doing the work?</p>
 <p>Apparently ROBUST is designed to allow code reuse.</p>
-<p>Note that this will allow us to easily integrate <a href="index.html">OMG</a>, as we can do that in any language, implement the relevant parts of the ROBUST wire protocol, listen on a given HTTP port, then just tell the ROBUST clients to use that port. <a href="Nails.html#command_pump">Nails:command pump</a> in fact includes provisions to have wrappers for other protocols, which is a perfect match here. So glad we don't have to deal with direct interfacing to C# code. B-)</p>
+<p>Note that this will allow us to easily integrate <a href="../index.html">OMG</a>, as we can do that in any language, implement the relevant parts of the ROBUST wire protocol, listen on a given HTTP port, then just tell the ROBUST clients to use that port. <a href="../common/Nails.html#command_pump">Nails:command pump</a> in fact includes provisions to have wrappers for other protocols, which is a perfect match here. So glad we don't have to deal with direct interfacing to C# code. B-)</p>
 <p>The ROBUST wire protocol looks like it's HTTP POSTs to the URL and port number. The POST includes the service name, and a verbose (XML, ewww) text command to that service.</p>
 <p>&nbsp;</p>
 <h2> sim server view </h2>
diff --git a/docs/Grid_data_flow.png b/docs/SledjHamr/Grid_data_flow.png
index 8324280..8324280 100644
--- a/docs/Grid_data_flow.png
+++ b/docs/SledjHamr/Grid_data_flow.png
Binary files differ
diff --git a/docs/LSL-functions-implemented.html b/docs/SledjHamr/LSL-functions-implemented.html
index 7126a49..7126a49 100644
--- a/docs/LSL-functions-implemented.html
+++ b/docs/SledjHamr/LSL-functions-implemented.html
diff --git a/docs/LuaSL-New-scripting-engine.html b/docs/SledjHamr/LuaSL-New-scripting-engine.html
index cae5300..9ceb7f8 100644
--- a/docs/LuaSL-New-scripting-engine.html
+++ b/docs/SledjHamr/LuaSL-New-scripting-engine.html
@@ -12,14 +12,14 @@ 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.</p>
 <h1> write our own </h1>
-<p>I had considered in the <a href="SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p>
+<p>I had considered in the <a href="../SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p>
 <p>"I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one."</p>
 <p>"I've been thinking of trying out Lua as a backend for LSL, and trying some micro threading style experiments."</p>
 <p>That's about the sum total of my plans and thoughts though. lol</p>
 <p>Here are some more random thoughts.</p>
 <p>Writing an entire scripting engine in a new language is a big job.</p>
 <p>Lua is meant to be embedded into other things as an internal scripting language. It has great features that let it be a meta language, you can make it look like other languages, or add other language concepts. Plus it's tiny. Being used by online games like WoW means it's probably got what it takes. These are reasons I chose it for both server side and client side scripting.</p>
-<p>My own personal plan was to cut my teeth on Lua by using <a href="http://www.enlightenment.org/">EFL</a> for a RL contract I'm working on, then add Lua scripting to the meta-impy viewer. It turns out that the EFL Lua support was not complete, but I managed to use it in that project anyway. My next Lua plans are to implement in EFL those things that project needed. I did not plan on working on a Lua based server side scripting engine until after I had implemented some of the <a href="index.html">OMG</a> plans. In particular, I want to do that stuff in C, and C is the natural partner for Lua. Adding Lua to .NET / mono is a whole can of worms I personally don't want to get stuck in.</p>
+<p>My own personal plan was to cut my teeth on Lua by using <a href="http://www.enlightenment.org/">EFL</a> for a RL contract I'm working on, then add Lua scripting to the meta-impy viewer. It turns out that the EFL Lua support was not complete, but I managed to use it in that project anyway. My next Lua plans are to implement in EFL those things that project needed. I did not plan on working on a Lua based server side scripting engine until after I had implemented some of the <a href="../index.html">OMG</a> plans. In particular, I want to do that stuff in C, and C is the natural partner for Lua. Adding Lua to .NET / mono is a whole can of worms I personally don't want to get stuck in.</p>
 <p>I have successfully completed my plans to implement EFL Lua things that my RL contract needed. That's in the current release of the EFL libraries, so I can move onto my next plans now.</p>
 <p>On the other hand, perhaps it's worthwhile starting on our own scripting engine now? It's a big job, so lets break it down.</p>
 <p>&nbsp;</p>
@@ -525,7 +525,7 @@ end
 <p>&nbsp;</p>
 <h3> changing the world </h3>
 <p>When our scripts want to change the world, we will have to convince OpenSim to do that for us. If we are really lucky, we can talk directly to the asset server. Might be able to just talk to the sims local database, but that gets tricky if the script engine is NOT running on the sim server, which is a possibility we want to keep open.</p>
-<p>For the functions that get and set prim properties, we should use wrappers around llSetPrimitiveParams() and friends. The <a href="Nails.html">Nails</a> protocol is partly based on those functions, so this will work out well for the future, when we move to a Nails command pump.</p>
+<p>For the functions that get and set prim properties, we should use wrappers around llSetPrimitiveParams() and friends. The <a href="../common/Nails.html">Nails</a> protocol is partly based on those functions, so this will work out well for the future, when we move to a Nails command pump.</p>
 <p>&nbsp;</p>
 <h3> Lifestyles of the rich and infamous... er I mean life cycle of a script, and communications with the engine. </h3>
 <p>Scripts start life currently in OpenSim, will get sent to the script engine to be compiled, than started or stopped, eventually might get deleted. While they are running, the script engine requests in world services, and responds to events. Each of these things needs OpenSim and the script engine to refer to specific scripts, can use script UUIDs for that. My basic idea is to run the script engine as a separate process, communicating over a socket to the OpenSim processes. Initially, just for ease of implementation, I'm thinking of sending function calls and parameters as Lua function calls, and getting the results back as Lua values. We can use Lua table syntax to provide the script UUID, which will be called "SID" in the following discussion.</p>
diff --git a/docs/BlackListAssetServersTracker.html b/docs/common/BlackListAssetServersTracker.html
index d080e87..d080e87 100644
--- a/docs/BlackListAssetServersTracker.html
+++ b/docs/common/BlackListAssetServersTracker.html
diff --git a/docs/NGIW.Commands.html b/docs/common/NGIW.Commands.html
index c058a6f..c058a6f 100644
--- a/docs/NGIW.Commands.html
+++ b/docs/common/NGIW.Commands.html
diff --git a/docs/NGIW.html b/docs/common/NGIW.html
index 9d5c039..dfe6f83 100644
--- a/docs/NGIW.html
+++ b/docs/common/NGIW.html
@@ -3,7 +3,7 @@
 <head>
 </head>
 <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
-<p>See also <a href="SledjHamr.html">SledjHamr</a></p>
+<p>See also <a href="../SledjHamr.html">SledjHamr</a></p>
 <p>Random thoughts about Next Generation Immersive Web, or whatever we call it.</p>
 <p>Here I want to indicate a possible design direction. The buzzword compliant summary is HTTP 1.1, REST and JSON.</p>
 <p>I don't want to descend into the actual messy details here, so I will make some simplifications. I will assume a simplified world where there are only two kinds of things, boxes and textures. Boxes have a position, a rotation, a size, and a single texture. The software architecture will be simplified to two elements of software, the simulator and the client.</p>
diff --git a/docs/Nails.html b/docs/common/Nails.html
index 4eca750..152549d 100644
--- a/docs/Nails.html
+++ b/docs/common/Nails.html
@@ -179,7 +179,7 @@
 <p>Some of this could be dealt with by treating the avatar as a prim. In fact, Alice's proposed animation system deals with animating avatars and prims the same way.</p>
 <p>&nbsp;</p>
 <h2> Animation commands. </h2>
-<p>Alice is working on that over at the <a href="BVJ.html">BVJ</a> page.</p>
+<p>Alice is working on that over at the <a href="../ClientHamr/BVJ.html">BVJ</a> page.</p>
 <p>&nbsp;</p>
 <h2> Meta commands. </h2>
 <p>0 SELECT_OBJECT key</p>
diff --git a/docs/OMG-WTF-BBQ.html b/docs/common/OMG-WTF-BBQ.html
index 5e48a14..5e48a14 100644
--- a/docs/OMG-WTF-BBQ.html
+++ b/docs/common/OMG-WTF-BBQ.html
diff --git a/docs/SledjHamr/README.Bookie b/docs/common/README.Bookie
index bec4b19..bec4b19 100644
--- a/docs/SledjHamr/README.Bookie
+++ b/docs/common/README.Bookie
diff --git a/docs/SledjHamr/README.libraries b/docs/common/README.libraries
index 8b99b7f..8b99b7f 100644
--- a/docs/SledjHamr/README.libraries
+++ b/docs/common/README.libraries
diff --git a/docs/ClientHamr/README.mumble b/docs/common/README.mumble
index 1010f18..1010f18 100644
--- a/docs/ClientHamr/README.mumble
+++ b/docs/common/README.mumble
diff --git a/docs/SledjHamr/The_Naminator.txt b/docs/common/The_Naminator.txt
index 0002d2e..0002d2e 100644
--- a/docs/SledjHamr/The_Naminator.txt
+++ b/docs/common/The_Naminator.txt
diff --git a/docs/SledjHamr/no_accounts.txt b/docs/common/no_accounts.txt
index 5ecbe08..5ecbe08 100644
--- a/docs/SledjHamr/no_accounts.txt
+++ b/docs/common/no_accounts.txt
diff --git a/docs/SledjHamr/portals.txt b/docs/common/portals.txt
index 28498c2..28498c2 100644
--- a/docs/SledjHamr/portals.txt
+++ b/docs/common/portals.txt
diff --git a/docs/SledjHamr/privacy.txt b/docs/common/privacy.txt
index 992867b..992867b 100644
--- a/docs/SledjHamr/privacy.txt
+++ b/docs/common/privacy.txt
diff --git a/docs/index.html b/docs/index.html
index db70d09..ce47ca2 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -15,41 +15,41 @@ Welcome to the home of SledjHamr!
 <li><a href="SledjHamr.html">SledjHamr</a> Tearing down the garden walls.</li>
 <li>Server side -</li>
 <ul>
-<li>We take <a href="SledjHamr/privacy.txt">privacy</a> seriously.</li>
+<li><a href="SledjHamr/LuaSL-New-scripting-engine.html">LuaSL</a> a new scripting engine, with extra speeeeeed!</li>
-<li><a href="SledjHamr/portals.txt">portals</a> Killer feature!</li>
-<li><a href="OMG-WTF-BBQ.html">OMG WTF BBQ</a> A means of making UUIDs location-agnostic.  This is where we deal with systems to keep track of where in the web assets are, and to cache them.</li>
-<li><a href="SledjHamr/no_accounts.txt">no accounts</a> We don need no stinkin' accounts.</li>
-<li><a href="NGIW.html">NGIW</a> REST is probably good to apply to the web server part.  Alice wants JSON to, but see nails.</li>
-<ul><li><a href="NGIW.Commands.html">NGIW.Commands</a> In the NGIW/REST world, how do I touch an object, or send it some other kind of message?</li></ul>
-<li><a href="SledjHamr/The_Naminator.txt">The Naminator</a> eliminates human readable names, to make way for computer names from SkyNet.  Or something.</li>
-<li><a href="LuaSL-New-scripting-engine.html">LuaSL</a> a new scripting engine, with extra speeeeeed!</li>
 <ul>
-<li><a href="LSL-functions-implemented.html">LSL functions implemented</a></li>
+<li><a href="SledjHamr/LSL-functions-implemented.html">LSL functions implemented</a></li>
 </ul>
 <li><a href="SledjHamr/README.Lspace">Lspace</a> Sim contents server.</li>
 <li><a href="SledjHamr/love.txt">love</a> makes the world go around.</li>
 <li>HamrSpace inventory server, a pocket universe where cartoon characters keep their giant hammers.</li>
-<li>Documenting the <a href="Grid-data-flow.html">flow of data</a> through an OpenSim system, so we can replace it.</li>
+<li>Documenting the <a href="SledjHamr/Grid-data-flow.html">flow of data</a> through an OpenSim system, so we can replace it.</li>
 </ul>
-<li><a href="Nails.html">Nails</a> bangs it all together, mostly via the command pump.</li>
+<li>We take <a href="common/privacy.txt">privacy</a> seriously.</li>
-<li><a href="ClientHamr/README.mumble">mumble</a> Voice integration.</li>
+<li><a href="common/portals.txt">portals</a> Killer feature!</li>
-<li>The various <a href="SledjHamr/README.libraries">libraries</a> used.</li>
+<li><a href="common/OMG-WTF-BBQ.html">OMG WTF BBQ</a> A means of making UUIDs location-agnostic.  This is where we deal with systems to keep track of where in the web assets are, and to cache them.</li>
+<li><a href="common/no_accounts.txt">no accounts</a> We don need no stinkin' accounts.</li>
+<li><a href="common/NGIW.html">NGIW</a> REST is probably good to apply to the web server part.  Alice wants JSON to, but see nails.</li>
+<ul><li><a href="common/NGIW.Commands.html">NGIW.Commands</a> In the NGIW/REST world, how do I touch an object, or send it some other kind of message?</li></ul>
+<li><a href="common/The_Naminator.txt">The Naminator</a> eliminates human readable names, to make way for computer names from SkyNet.  Or something.</li>
+<li><a href="common/Nails.html">Nails</a> bangs it all together, mostly via the command pump.</li>
+<li><a href="common/README.mumble">mumble</a> Voice integration.</li>
+<li>The various <a href="common/README.libraries">libraries</a> used.</li>
 <li><a href="Croquet-integration.html">Croquet integration</a>  Just an idea, but we should support other virtual world tech if we can.</li>
-<li><a href="ClientHamr.html">ClientHamr</a> How to rip code out of the client and make it better.</li>
+<li><a href="ClientHamr/ClientHamr.html">ClientHamr</a> How to rip code out of the client and make it better.</li>
 <ul>
 <li><a href="ClientHamr/README.woMan">woMan</a> Virtual world  account and viewer manager.</li>
 <li>How to deal with sucky <a href="ClientHamr/WebBrowsers.txt">web browsers</a>.</li>
 <li><a href="ClientHamr/TellinBone.txt">TellinBone</a> A virtual Android "phone".</li>
 <li>Blue sky <a href="ClientHamr/ScriptEditor.txt">script editor</a> idea, will the stars align?</li>
 <li><a href="ClientHamr/README.purkle">purkle</a> Jabber / XMPP integration.</li>
-<li><a href="InworldAnimationEditor.html">InworldAnimationEditor</a> I dream of mixing qavimator into the client.</li>
+<li><a href="ClientHamr/InworldAnimationEditor.html">InworldAnimationEditor</a> I dream of mixing qavimator into the client.</li>
 <li><a href="ClientHamr/README.GuiLua">GuiLua</a> Skang for SledjHamr.</li>
 <li><a href="ClientHamr/README.extantz">extantz</a> The viewer.</li>
-<li><a href="BVJ.html">BVJ</a> New and improved animations, with extra attachment points included.</li>
+<li><a href="ClientHamr/BVJ.html">BVJ</a> New and improved animations, with extra attachment points included.</li>
-<li><a href="BlackListAssetServersTracker.html">BlackListAssetServersTracker</a> Might be cool if you could accept/reject asset servers.  For copyright control or to avoid seeing yucky stuff.</li>
 <li><a href="ClientHamr/README.bGod">bGod</a> Admin / manager tools.</li>
 </ul>
-<li><a href="SledjHamr/README.Bookie">Bookie</a> Dealing with libraries.</li>
+<li><a href="common/README.Bookie">Bookie</a> Dealing with libraries.</li>
+<li><a href="common/BlackListAssetServersTracker.html">BlackListAssetServersTracker</a> Might be cool if you could accept/reject asset servers.  For copyright control or to avoid seeing yucky stuff.</li>
 </ul>
 <p>We have a code repo on github now - <a href="https://github.com/onefang/SledjHamr">https://github.com/onefang/SledjHamr</a> with just a small README that points to this page.  The experimental branch has all the actual code and stuff.  We can finally start writing code.  A local copy of <a href="/source/">the source</a> can be found here.</p>
 <p>Now that we have a web site, I should turn this into a real web site, huh?</p>