Bumpity Bump. If I don't hear any comments on this, I'm going to assume the 
proposal is sound and have carte blanche to break OpenSim at my whim. ;)

(find the original post for the attachment.)

Regards,

Adam

From: [email protected] 
[mailto:[email protected]] On Behalf Of Frisby, Adam
Sent: Friday, 11 December 2009 3:48 AM
To: [email protected]
Subject: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Hi Folks,

I've got a fairly complicated proposal to deliver here today - the short of it 
is; I'd like to go ahead and replace the current Scene Object representation 
model - at a fairly comprehensive & complete level. Some of you have had the 
misfortune of working with SceneObjectPart/SceneObjectGroup and should 
understand what I am talking about.

There are several stages to this proposal - but I would like to talk about 
today the first big one (and a small outline of the larger project - the reason 
for this being some of the later details require a little more nutting out 
before I have a complete proposal for them).

So - the larger proposal in a nutshell; I would like to:

*         Merge SceneObjectGroup & SceneObjectPart

*         Enable full inheritance & linking (ie, hierarchical linking)

*         Make programming with SceneObjects possible & reasonable from the 
outside (ie have a clean API).

*         Provide the ability to extend SceneObjects with "components" to 
introduce new properties and behaviours.

The item I'd like to talk about today would be implementing Components. 
Components are small C# classes that may be attached to any SceneObject 
arbitrarily.

A component is any class inheriting from IComponent - IComponent carries only 
two properties; a serialisation property (returns the current 'state' for 
serialisation purposes), and a type property (which recognises the 'type' of 
component that it is) - components allow you to attach arbitrary data to an 
object for the purposes of interacting with a region module. For instance, a 
"Mesh" module (which is my current best example) would have a MeshComponent 
that included all the extra data to tag an object with related to meshes - 
which would get serialised and passed around with the main object. When 
deserialized - a "Factory" handles making sure the MeshComponent is 
deserialized with the main object.

I've attached a document which is my current state of the whole proposal which 
includes some examples & more detail. Please note that Phase 2 is not finalised 
yet - and some decisions were discussed about changing two facets in particular.

*         Enabling inheritance of components+sceneobject to make speedy-classes 
for common use cases (eg PrimObject inherits PrimComponent and SceneObject)

*         Allowing more than one factory potentially; for manufacturing said 
speedy-classes.

*         Note that these shorthand classes would still use the standard .Has / 
.Get methods; they would just return 'this' where the particular component type 
is concerned.

To begin with - I would like to implement components as an extra non-serialised 
property of the SceneObjectPart; this will occur very shortly after 0.7 is 
tagged; which I would like to do once ROBUST covers all the main services (I 
heard something about late-december/early-jan); this first stage should not 
break anything in particular - however once that Is complete, I would like to 
migrate properties into components in order to modularised the codebase better.

An example of this would be PrimData - primdata is unique to the Second Life 
use case, and irrelevant to others; in this case, we'll move PrimData into a 
commonly accessed component (eg "SceneObject.Get<PrimData>.Hollow = 0.9f;") - 
once the move to components is complete for the common data; then creating the 
final SceneObject class which merges SceneObjectGroup+Part should be a fairly 
painless process.

Please take a read of the document attached for more information - and I am 
very keen to hear anyones thoughts as to use cases that this model will make 
more difficult; or could not support. The goal with this project is to make 
OpenSim support more with less - allowing third party modules to really take 
OpenSim as a framework to the next level; and make a more modular server for 
other clients & platforms.

Thanks!

Adam
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to