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

[Justin Clark-Casey]

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