[Opensim-dev] Should SOG and SOP be combined into a single object in a linked hierarchy?
Alan M Webb
alan_webb at us.ibm.com
Tue Nov 11 14:55:39 UTC 2008
Arriving late to this discussion. Why is a single super class not the
answer here? llEntity contains the information which is true of all
elements, then derived classes differentiate based upon usage? One, large,
monolithic class makes things easy in the short-term, but harder over time
and totally defeats the design goals of an object oriented system. IMHO
:-)
Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb at us.ibm.com
From:
Melanie <melanie at t-data.com>
To:
opensim-dev at lists.berlios.de
Date:
11/10/2008 10:07 PM
Subject:
Re: [Opensim-dev] Should SOG and SOP be combined into a single object in
a linked hierarchy?
Yes. That is one of the main points. I think I can bring
hierarchical linking even to the LL viewer with that concept of just
one object type.
Melanie
Dahlia Trimble wrote:
> Would this proposal allow linksets to be children of other linksets?
> (assuming we would ever want that)
>
> On Mon, Nov 10, 2008 at 8:08 AM, Justin Clark-Casey <
> jjustincc at googlemail.com> wrote:
>
>> Somewhat separately from Adam's other post, I'd like to raise this
issue on
>> the mailing list since it keeps popping up.
>> I'll confess that I'm not 100% convinced yet that SOG and SOP should
>> simply be combined, though I do accept that the
>> code does need some architectural changes. Unfortunately, I'm not
quite up
>> to drawing diagrams yet.
>>
>> This discussion may also have come up on the mailing list in some way
>> before so references are welcome, as are
>> clarifications to the statements below.
>>
>> Melanie's proposal, as I understand it, is to combine the current SOG
and
>> SOP into a single object (let's call it
>> LLEntity). LLEntity's would be linked into a tree, so there can be
>> something like
>>
>>
>> LLEntity
>> / | \
>> / | \
>> / | \
>> / | \
>> LLEntity LLEntity LLEntity
>> |
>> |
>> LLEntity
>>
>>
>>
>> Here are some of the pros and cons as I see them. Adam has already
talked
>> about some of these in his blog post.
>>
>> Pros
>>
>> 1. At the moment we can only have one level of prim linking (as
>> effectively dictated by the LL Second Life client).
>> Linking into a tree would allow multiple levels of linking (though with
the
>> assumption of single parents).
>>
>> 2. It makes manipulation of prims much easier. Instead of having to
>> reference SOPs in and out of SOG, everything is
>> done on a single class. Some properties can be set on a SOP reference
>> without having to worry about whether they are a
>> root SOP or not (see below).
>>
>> 3. The Second Life client protocol wants to manipulate SOPs directly
in
>> many situations (e.g. individual prim selection
>> of a group, the fact that local ids are passed around that reference
prims
>> rather than linksets).
>>
>> 4. Get rid of the root part checks on object deletion. However, a lot
of
>> these come from the fact that we null out
>> m_rootPart after object deletion when there may be no need to - I'm
>> anticipating that extraneous info sent to a viewer
>> about a deleted object will be simply ignored. This is a change we
should
>> try soon now that we're at the start of a
>> release process.
>>
>>
>> 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.
>>
>> 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
>>
>> public virtual Vector3 Velocity
>> {
>> get { return m_velocity; }
>> set { m_velocity = value; }
>> }
>>
>> becomes something like
>>
>> public virtual Vector3 Velocity
>> {
>> get
>> {
>> if (ParentEntity != null)
>> return ParentEntity.Velocity;
>> else
>> return m_velocity;
>> }
>>
>> set
>> {
>> if (ParentEntity != null)
>> ParentEntity.Velocity = value;
>> else
>> m_velocity = value;
>> }
>> }
>>
>> 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).
>>
>> 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.
>>
>>
>> This isn't a full set of pros and cons, just the ones that occur to me
>> right now. I'm sorry this is a long post but I
>> feel that we need to a get a long form view of this as change here will
>> stay with us for a considerable time into the
>> future. If there isn't any major discussion then this may go ahead
anyway
>> (since Melanie, for one, is quite keen and I
>> may be the only person really bothered about this).
>>
>> 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.
>>
>> --
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081111/1f787b00/attachment-0001.html>
More information about the Opensim-dev
mailing list