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

[Frisby, Adam]

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