Would this proposal allow linksets to be children of other linksets? (assuming we would ever want that)<br><br><div class="gmail_quote">On Mon, Nov 10, 2008 at 8:08 AM, Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Somewhat separately from Adam's other post, I'd like to raise this issue on the mailing list since it keeps popping up.<br>
I'll confess that I'm not 100% convinced yet that SOG and SOP should simply be combined, though I do accept that the<br>
code does need some architectural changes. Unfortunately, I'm not quite up to drawing diagrams yet.<br>
<br>
This discussion may also have come up on the mailing list in some way before so references are welcome, as are<br>
clarifications to the statements below.<br>
<br>
Melanie's proposal, as I understand it, is to combine the current SOG and SOP into a single object (let's call it<br>
LLEntity). LLEntity's would be linked into a tree, so there can be something like<br>
<br>
<br>
LLEntity<br>
/ | \<br>
/ | \<br>
/ | \<br>
/ | \<br>
LLEntity LLEntity LLEntity<br>
|<br>
|<br>
LLEntity<br>
<br>
<br>
<br>
Here are some of the pros and cons as I see them. Adam has already talked about some of these in his blog post.<br>
<br>
Pros<br>
<br>
1. At the moment we can only have one level of prim linking (as effectively dictated by the LL Second Life client).<br>
Linking into a tree would allow multiple levels of linking (though with the assumption of single parents).<br>
<br>
2. It makes manipulation of prims much easier. Instead of having to reference SOPs in and out of SOG, everything is<br>
done on a single class. Some properties can be set on a SOP reference without having to worry about whether they are a<br>
root SOP or not (see below).<br>
<br>
3. The Second Life client protocol wants to manipulate SOPs directly in many situations (e.g. individual prim selection<br>
of a group, the fact that local ids are passed around that reference prims rather than linksets).<br>
<br>
4. Get rid of the root part checks on object deletion. However, a lot of these come from the fact that we null out<br>
m_rootPart after object deletion when there may be no need to - I'm anticipating that extraneous info sent to a viewer<br>
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<br>
release process.<br>
<br>
<br>
Cons<br>
<br>
1. LLEntity becomes very large and potentially complex. SOG and SOP are already large and complex. It may be possible<br>
to improve this by further refactoring.<br>
<br>
2. Every setting and getting of a property in LLEntity has to delegate up to its root LLEntity unless it is the root.<br>
Therefore, code such as<br>
<br>
public virtual Vector3 Velocity<br>
{<br>
get { return m_velocity; }<br>
set { m_velocity = value; }<br>
}<br>
<br>
becomes something like<br>
<br>
public virtual Vector3 Velocity<br>
{<br>
get<br>
{<br>
if (ParentEntity != null)<br>
return ParentEntity.Velocity;<br>
else<br>
return m_velocity;<br>
}<br>
<br>
set<br>
{<br>
if (ParentEntity != null)<br>
ParentEntity.Velocity = value;<br>
else<br>
m_velocity = value;<br>
}<br>
}<br>
<br>
One also needs to be careful to set the publicly available property so that delegation happens if required, rather than<br>
the private field to avoid state such as 'attached' becoming inconsistent (this is a potential source of bugs).<br>
<br>
3. It leads to an increase in property duplication at the database and serialization levels. Every LLEntity will have<br>
a set of fields, even though some of those conceptually only apply to a linkset/SceneObjectGroup. This probably isn't<br>
serious but I think that it will make things harder to work with at those levels.<br>
<br>
<br>
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<br>
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<br>
future. If there isn't any major discussion then this may go ahead anyway (since Melanie, for one, is quite keen and I<br>
may be the only person really bothered about this).<br>
<br>
At the moment I'm actually leaning towards the single LLEntity suggestion, though I'm a little concerned about the<br>
duplication that ends up at the database/serialization level. But I'd really like to hear what other people think.<br>
<font color="#888888"><br>
--<br>
justincc<br>
Justin Clark-Casey<br>
<a href="http://justincc.wordpress.com" target="_blank">http://justincc.wordpress.com</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</font></blockquote></div><br>