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

Frisby, Adam adam at deepthink.com.au
Tue Nov 11 16:48:52 UTC 2008 

No, I do agree Croquet and SL objects will probably never mix - so that's a safe one to say 'well, if you want to do that you're going to have to rip up some code'.

However, we might end up with another client that has linking rules similar to this - but has different properties - in that case, we're already dealing with LLEntity in places where BaseSop might be more appropriate.

Regards,

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Tuesday, 11 November 2008 8:15 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?
>
> 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
> >
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

More information about the Opensim-dev mailing list