On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <span dir="ltr"><<a href="mailto:adam@deepthink.com.au">adam@deepthink.com.au</a>></span> wrote:
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-AU"><div><p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Enable full inheritance & linking (ie, hierarchical
linking)</p></div></div></blockquote><br>This is terrific news, Adam!<br><br>There's a bunch of us who have been "hierarchical object activists" in SL for some years, regularly trying to get the benefits of hierarchical objects across to Linden developers at their Office Hours. We have a wiki page on <a href="https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy">Prim and Object Hierarchy</a> , and a number of Jiras also address the issue, including <a href="http://jira.secondlife.com/browse/MISC-428">MISC-428</a>, <a href="http://jira.secondlife.com/browse/MISC-1434">MISC-1434</a>, and <a href="http://jira.secondlife.com/browse/MISC-2237">MISC-2237</a>.<br>
<br>We've been successful <i>on the principle</i> (several LL devs now support it wholeheartedly) but not in practice, because the development process within the Labs appears to be quite logjammed and stifled so that individual developer opinion has no effect. As noted on the wiki page above though, Lindens <i>know</i> that they made a mistake in not supporting object hierarchy. They just can't do anything about it now.<br>
<br>Hierarchical objects provide many different types of benefit, so you'll hear different people advocate different aspects about them, but they're all complementary. My angle stems from the needs of pure engineering, in that hierarchical object composition is the basis of all engineered products in RL. Almost everything in modern life is manufactured by putting together <i>complex components</i>, not from raw materials, and that's how you ride on the shoulders of giants. You can't do that in SL.<br>
<br>It's wonderful to see hierarchical objects finally gaining in profile in Opensim. Is there a design for this?<br><br>We've been examining the pro's and con's of various approaches, including evolutionary ones that extend the current very poor linkset paradigm, as well as new designs that either encapsulate linksets transparently or else create a completely new and separate hierarchical object system in parallel with the current non-hierarchical one. Each approach has its own advantages and disadvantages.<br>
<br>More info on your current thinking would be very welcome. Designs tend to stick around for longer than planned, and getting it partially right from the start would be a good idea.<br><br>Morgaine.<br><br><br><br><br>
==============================<br><br><div class="gmail_quote">On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <span dir="ltr"><<a href="mailto:adam@deepthink.com.au">adam@deepthink.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-AU">
<div>
<p class="MsoNormal">Hi Folks,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I’ve got a fairly complicated proposal to deliver here
today – the short of it is; I’d like to go ahead and replace the
current Scene Object representation model – at a fairly comprehensive
& complete level. Some of you have had the misfortune of working with
SceneObjectPart/SceneObjectGroup and should understand what I am talking about.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">There are several stages to this proposal – but I
would like to talk about today the first big one (and a small outline of the
larger project – the reason for this being some of the later details
require a little more nutting out before I have a complete proposal for them).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">So – the larger proposal in a nutshell; I would like
to:</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Merge SceneObjectGroup & SceneObjectPart</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Enable full inheritance & linking (ie, hierarchical
linking)</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Make programming with SceneObjects possible
& reasonable from the outside (ie have a clean API).</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Provide the ability to extend SceneObjects with “components”
to introduce new properties and behaviours.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The item I’d like to talk about today would be
implementing Components. Components are small C# classes that may be attached
to any SceneObject arbitrarily. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">A component is any class inheriting from IComponent –
IComponent carries only two properties; a serialisation property (returns the
current ‘state’ for serialisation purposes), and a type property (which
recognises the ‘type’ of component that it is) – components allow
you to attach arbitrary data to an object for the purposes of interacting with
a region module. For instance, a “Mesh” module (which is my current
best example) would have a MeshComponent that included all the extra data to
tag an object with related to meshes – which would get serialised and
passed around with the main object. When deserialized – a “Factory”
handles making sure the MeshComponent is deserialized with the main object.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I’ve attached a document which is my current state of
the whole proposal which includes some examples & more detail. Please note
that Phase 2 is not finalised yet – and some decisions were discussed
about changing two facets in particular.</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Enabling inheritance of components+sceneobject
to make speedy-classes for common use cases (eg PrimObject inherits
PrimComponent and SceneObject)</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Allowing more than one factory potentially; for
manufacturing said speedy-classes.</p>
<p><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span>Note that these shorthand classes would still
use the standard .Has / .Get methods; they would just return ‘this’
where the particular component type is concerned.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">To begin with – I would like to implement components
as an extra non-serialised property of the SceneObjectPart; this will occur
very shortly after 0.7 is tagged; which I would like to do once ROBUST covers
all the main services (I heard something about late-december/early-jan); this
first stage should not break anything in particular – however once that Is
complete, I would like to migrate properties into components in order to
modularised the codebase better.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">An example of this would be PrimData – primdata is
unique to the Second Life use case, and irrelevant to others; in this case, we’ll
move PrimData into a commonly accessed component (eg “SceneObject.Get<PrimData>.Hollow
= 0.9f;”) – once the move to components is complete for the common
data; then creating the final SceneObject class which merges
SceneObjectGroup+Part should be a fairly painless process.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Please take a read of the document attached for more
information – and I am very keen to hear anyones thoughts as to use cases
that this model will make more difficult; or could not support. The goal with
this project is to make OpenSim support more with less – allowing third
party modules to really take OpenSim as a framework to the next level; and make
a more modular server for other clients & platforms.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks!</p>
<p class="MsoNormal"> </p><font color="#888888">
<p class="MsoNormal">Adam</p>
</font></div>
</div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br>