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

Justin Clark-Casey jjustincc at googlemail.com
Tue Nov 11 14:50:41 UTC 2008


Melanie wrote:
> 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.

Personally I disagree - any large and complex class is a result to be avoided.

However, as I said, I suspect that it could be broken up somewhat (unless you want absolutely everything in a single 
class on principle).  For instance, all the inventory stuff should really be in a separate class, especially as one can 
imagine virtual environments either where prims don't have inventory, or where inventory is handled different (e.g. an 
inventory for the whole object rather than for individual prims).

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

It's going to look pretty messy.  Almost every single property and method would need to potentially delegate up to a 
root entity.  If we ever get to deeply linked sets this could add up to quite a few method calls.  However, I personally 
don't think this is an issue.

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

One person writing and maintaining is a bad solution.  The code should be written in such a way that as many people can 
maintain it and safely change it as possible, not just one person.  But I do agree that maintaining consistency would 
only be a problem within the entity class itself.

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

That's true, though arguably for some properties this isn't correct.  For instance, region handle is present in every 
prim even though it arguably only ever applies to objects as a whole.  This forces us to have extra code for locking and 
making sure things are consistent (though under a 'root entity' scheme this largely wouldn't be an issue, as long as 
people set properties rather than member fields directly).  Anyway, there aren't many such properties.

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

Yeah, I'm leaning towards this now.  However, I'd still like to wait until the weekend, at least, for any other input. 
This change will require code changes in lots of areas, including some currently being worked (such as the EntitiesList) 
so it would be good to try and see if anybody can see any major obstacles ahead before plunging in.

> 
> Melanie
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com



More information about the Opensim-dev mailing list