[Opensim-dev] Should SOG and SOP be combined into a single object in a linked hierarchy?

[Melanie]

Yes. That is one of the main points. I think I can bring 
hierarchical linking even to the LL viewer with that concept of just 
one object type.

Melanie


Dahlia Trimble wrote:
> Would this proposal allow linksets to be children of other linksets?
> (assuming we would ever want that)
> 
> On Mon, Nov 10, 2008 at 8:08 AM, Justin Clark-Casey <
> jjustincc at googlemail.com> wrote:
> 
>> Somewhat separately from Adam's other post, I'd like to raise this issue on
>> the mailing list since it keeps popping up.
>>   I'll confess that I'm not 100% convinced yet that SOG and SOP should
>> simply be combined, though I do accept that the
>> code does need some architectural changes.  Unfortunately, I'm not quite up
>> to drawing diagrams yet.
>>
>> This discussion may also have come up on the mailing list in some way
>> before so references are welcome, as are
>> clarifications to the statements below.
>>
>> Melanie's proposal, as I understand it, is to combine the current SOG and
>> SOP into a single object (let's call it
>> LLEntity).  LLEntity's would be linked into a tree, so there can be
>> something like
>>
>>
>>            LLEntity
>>           /    |   \
>>          /     |    \
>>         /      |     \
>>        /       |      \
>> LLEntity   LLEntity    LLEntity
>>                |
>>                |
>>            LLEntity
>>
>>
>>
>> Here are some of the pros and cons as I see them.  Adam has already talked
>> about some of these in his blog post.
>>
>> Pros
>>
>> 1.  At the moment we can only have one level of prim linking (as
>> effectively dictated by the LL Second Life client).
>> Linking into a tree would allow multiple levels of linking (though with the
>> assumption of single parents).
>>
>> 2.  It makes manipulation of prims much easier.  Instead of having to
>> reference SOPs in and out of SOG, everything is
>> done on a single class.  Some properties can be set on a SOP reference
>> without having to worry about whether they are a
>> root SOP or not (see below).
>>
>> 3.  The Second Life client protocol wants to manipulate SOPs directly in
>> many situations (e.g. individual prim selection
>> of a group, the fact that local ids are passed around that reference prims
>> rather than linksets).
>>
>> 4.  Get rid of the root part checks on object deletion.  However, a lot of
>> these come from the fact that we null out
>> m_rootPart after object deletion when there may be no need to - I'm
>> anticipating that extraneous info sent to a viewer
>> about a deleted object will be simply ignored.  This is a change we should
>> try soon now that we're at the start of a
>> release process.
>>
>>
>> Cons
>>
>> 1.  LLEntity becomes very large and potentially complex.  SOG and SOP are
>> already large and complex.  It may be possible
>> to improve this by further refactoring.
>>
>> 2.  Every setting and getting of a property in LLEntity has to delegate up
>> to its root LLEntity unless it is the root.
>> Therefore, code such as
>>
>>         public virtual Vector3 Velocity
>>         {
>>             get { return m_velocity; }
>>             set { m_velocity = value; }
>>         }
>>
>> becomes something like
>>
>>         public virtual Vector3 Velocity
>>         {
>>             get
>>             {
>>                 if (ParentEntity != null)
>>                     return ParentEntity.Velocity;
>>                 else
>>                     return m_velocity;
>>             }
>>
>>             set
>>             {
>>                 if (ParentEntity != null)
>>                    ParentEntity.Velocity = value;
>>                 else
>>                    m_velocity = value;
>>             }
>>         }
>>
>> One also needs to be careful to set the publicly available property so that
>> delegation happens if required, rather than
>> the private field to avoid state such as 'attached' becoming inconsistent
>> (this is a potential source of bugs).
>>
>> 3.  It leads to an increase in property duplication at the database and
>> serialization levels.  Every LLEntity will have
>> a set of fields, even though some of those conceptually only apply to a
>> linkset/SceneObjectGroup.  This probably isn't
>> serious but I think that it will make things harder to work with at those
>> levels.
>>
>>
>> This isn't a full set of pros and cons, just the ones that occur to me
>> right now.  I'm sorry this is a long post but I
>> feel that we need to a get a long form view of this as change here will
>> stay with us for a considerable time into the
>> future.  If there isn't any major discussion then this may go ahead anyway
>> (since Melanie, for one, is quite keen and I
>> may be the only person really bothered about this).
>>
>> At the moment I'm actually leaning towards the single LLEntity suggestion,
>> though I'm a little concerned about the
>> duplication that ends up at the database/serialization level.  But I'd
>> really like to hear what other people think.
>>
>> --
>> justincc
>> Justin Clark-Casey
>> http://justincc.wordpress.com
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev