Bravo, Morgaine. Well done indeed. :)<div><br></div><div>Cheers</div><div><br><br><div class="gmail_quote">On Mon, Nov 23, 2009 at 5:12 PM, Kyle <span dir="ltr"><<a href="mailto:create@reactiongrid.com">create@reactiongrid.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">What she said! Thank you Morgaine for clarifying this for all of
us. In my opinion this discussion was appropriate here to understand roadmap
and documentation efforts. Thanks for caring to let the rest of the community
hear about your very smart opinions. More talk like this will bring the
community together wherever it occurs.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>
[mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>] <b>On Behalf Of </b>Morgaine<br>
<b>Sent:</b> Monday, November 23, 2009 6:04 PM</span></p><div class="im"><br>
<b>To:</b> <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
<b>Subject:</b> Re: [Opensim-dev] Leaving Project</div><p></p>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <<a href="mailto:lenwbrown@gmail.com" target="_blank">lenwbrown@gmail.com</a>> wrote:</p><div><div></div><div class="h5">
<p class="MsoNormal"> </p>
<div style="margin-left:30.0pt">
<p class="MsoNormal">For me the shock came when I was abruptly informed that <b>"OpenSim
is not Second Life, is not intended to be like Second Life, nor ever
will."</b> I still haven't the foggiest idea what this developer had
smoked for them to so strongly assert that incredibly false statement.</p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
Len, let me give you an alternative perspective on that quote to help you see
the reasons for it. I'm not on the Opensim team, but after five years in
SL, two years in AWG, and a year of working on future VW protocols in our IETF
group, I have some background to know why Opensim needs to distance itself from
SL:</p>
<ul type="disc">
<li class="MsoNormal">SL's statically tiled resource architecture is
badly <b>non-scalable</b>, because most resource usage in VWs cannot be
statically mapped (demand moves around). The inability to assign
resources dynamically in SL results in huge overload in busy places and
gross wastage in idle areas. It also limits the number of
participants in events and the bandwidth of their interaction, as well as
the size and complexity of everything in a region. This architecture
is fundamental to SL, yet it is a recipe for failure. As long as
Opensim adheres to the SL model, Opensim will be similarly non-scalable.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">The LSL scripting language is linguistically
weak, semantically obscure, and lacking in the glue that could allow
components to cooperate effectively. As a result, individual scripts
are quite underpowered and inefficient, and multi-script constructions do
not scale well in complexity because the overheads of cooperation are so
large. That's a bad restriction on progress which Opensim needs to
leave behind.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">LSL scripts are not scalable in power or size,
and this will continue to be true even after SL allows C# and other CLR
languages to be used. There is no possibility of using more CPU
power for scripting than is available in one single simulator in SL.
That is not a good foundation upon which to build an ambitious future of
clever components.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">SL's simulation environment is non-portable,
having evolved over time into a plethora of special cases that will not be
accurately replicable anywhere else. In effect this means that there
will never be effective interop with SL's scripted objects. It would
not be a useful goal to seek compatibility with what could realistically
be described as an "ill-defined mess".</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">SL's object and type systems are <b>non-extensible</b>,
so compatibility with SL means living in the past, and worse, living in a
past defined entirely by one slow-moving company. Tying the
capabilities of Opensim to that millstone would be a disaster --- it would
ensure the death of Opensim versus any extensible alternative that may
appear. Developing new extensible forms of world data beyond SL's
original set is a must for Opensim's survival as a modern VW platform.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">SL's viewer has deep knowledge of SL semantics
because the client and server were designed for each other rather than
designed as endpoints of a standard protocol. This has the very bad
consequence that future VW viewers would need to know about SL specifics
in order to interoperate with SL, which is a poor approach that doesn't
scale to metaverse-wide diversity. Opensim needs to leave
world-specific kludges behind if it has ambitions to underpin a highly
diverse metaverse of worlds, and this means leaving the SL viewer behind.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">SL's constructed objects are <b>non-hierarchical</b>,
which means that creators cannot use objects created by others as
subcomponents. This restriction completely blocks the hierarchical
engineering process that is the basis of progress in RL. In SL you
always have to build from "raw materials", so it is not possible
to ride on the shoulders of giants, nor harness a huge pyramid of people
skills. Even Philip and Cory Linden admitted that this was a mistake
-- see <a href="https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy" target="_blank">https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy</a>
. We don't want to live with their mistake.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">SL is based on highly <b>centralized</b> concepts
of <i>identity, storage and control</i>, which come together to create
either a walled garden or a prison planet, depending on one's
perspective. Whatever one's worldview, the end result is badly
non-scalable in those three areas. SL suffers hugely from that
non-scalability despite the relatively small size of the service at this
early stage. Opensim needs decentralized / distributed mechanisms for
<i>identity, storage and control</i> if it is to scale for Internet-wide
adoption.</li>
</ul>
<p class="MsoNormal"> </p>
<ul type="disc">
<li class="MsoNormal">From a futurist angle, Second Life has very
narrow horizons and barely pays lip service to the <b><i>virtual</i></b>
aspect of "virtual worlds". Nobody could claim that a
Flatland of square land tiles all featuring the same Earth-like look and
physics pushes the envelope of the imagination. To boldly go where
Lindens did not go before (topologically and geographically or spatially)
will be one of the most appreciated developments in Opensim. SL's
obsession with RL is an unwanted constraint in VWs, and we need to go
beyond it.</li>
</ul>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
That is not the full list of problems with SL, but hopefully it serves to
illustrate some of the concerns that VW developers have to consider in the
light of the SL legacy. While Linden Lab deserves much applause for their
vision and for their work in creating Second Life, many years have now passed,
and lessons have been learned. Compatibility with SL must not be the end
goal of Opensim because of issues like those highlighted above.<br>
<br>