1 files changed, 1 insertions, 1 deletions
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/SledjHamr.html b/docs/SledjHamr.html index b2371f1..304c884 100644 --- a/docs/SledjHamr.html +++ b/docs/SledjHamr.html
@@ -8,7 +8,7 @@
8	<p>This might sometimes be referred to as SledjHamr, SldjHmr, NGIW,or the term that currently has favour - Open Magic Garden (OMG).</p>	8	<p>This might sometimes be referred to as SledjHamr, SldjHmr, NGIW,or the term that currently has favour - Open Magic Garden (OMG).</p>
9	<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>	9	<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>
10	<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>	10	<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>
11	<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>	11	<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>
12	<p> </p>	12	<p> </p>
13	<h2> boxen </h2>	13	<h2> boxen </h2>
14	<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>	14	<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>