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

[Melanie]

Hi,


Justin Clark-Casey wrote:
> 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.

One large and complex class to make the other logic everywhere much 
simpler. A worthwhile tradeoff, i'd say.


> 
> 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

Yes. It puts that complexity in one place, rather than all over. I'd 
rather have one central point wher ethis is checked, than having to 
check it in tens of places.

> 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).

Keeping consistency is mostly the responsibility of the link/unlink 
code. Which I already volunteered to write and maintain, if that was 
all that's stopping it.

> 
> 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.
> 

If using automatic dot net serialization, that may be so. If using 
manual serialization, it doesn't have to be so.

In the database, we have that now. There is no rootprims and 
childprims table, just prims.

> 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.
> 

Well, I'd be on blard to help make sure it results in an elegant, 
easy to use class that is a joy to manipulate

Melanie