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

[Melanie]

Hi,

I think the current idea is IEntity (Entity?) -> LLEntity. 
LLEntities have all the LL viewer needs/is capable of. That includes 
such properties as linkability as well as specifics like shape.

Internally, LLEntity may delegate to other classes and/or helpers. 
But LLEntity should provide a single interface to what an LL entity 
can do.

I think there is little sense in linking apples with pears, e.g. 
non-LL objects with LL objects. Even with translation layers, I 
think linking has to be limited to linking one object type only, 
using it's own semantics. Even when mixing different object types in 
one scene. Linking, say, a Croquet mesh to a LL prim, I don't see 
that happening.

Melanie


Frisby, Adam wrote:
> If we do it this way, could we have an base class containing just the link descriptions, and recursive handling of properties to sequential parents?
> 
> IE:
> 
>         BaseSop : IEntity {
>                 List<BaseSop> m_parents;
>                 List<BaseSop> m_childroons;
> 
>                 void ForeachParent(delegate(BaseSop e) x);
>                 ... etc
> 
>                 Position
>                 Name
>                 ID
>                 Scale
>                 Rotation
>                 ... etc
>         }
> 
> Then if this is embedded everywhere we might stand a chance of having it useful for other VW's than SL. (IE the SL-specific properties (like say 'Shape') go into LLSop : BaseSop)
> 
> Regards,
> 
> Adam
> 
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey
>> Sent: Tuesday, 11 November 2008 6:51 AM
>> To: opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] Should SOG and SOP be combined into a single
>> object in a linked hierarchy?
>>
>> 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
>> _______________________________________________
>> 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
> 
>