[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Tue Dec 15 16:33:43 UTC 2009

Well, some people have rather complex extensions:

Combat modules
Script engines
Traffic simulations
Scientific simulations
E-Learning

etc... to cite just a few I know of.

I think this needs to be said up front. It's not goign to be easy.
And you can say that again. That's not to say that i doesn't have to
be done.

I'm all for it, it's needed to make progress. I'm prepared to carry
my part of the rewriting of my stuff.

What I intend to do is make it very clear, it's not easy sailing,
not 3-line changes here. To forestall the cries later. Who wants
angry mobs with torches and pitchforks, after all?

Melanie

Frisby, Adam wrote:
> Not too too painful. The vast majority should be cut&paste-able.
> 
> The big stuff will be people who have code tied to SOG/SOP on any deep level - however again, a lot of it should be transportable; it's going to require a healthy amount of refactoring unfortunately however.
> 
> I had a longer reply to this which is still sitting open - I'll get to it once I finish a little accounting work.
> 
> 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, 15 December 2009 8:05 AM
>> To: diva at metaverseink.com; opensim-dev at lists.berlios.de
>> Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing
>> Components
>> 
>> Hi,
>> 
>> in fact, yes. Anyone who has private modules is in for a rather
>> painful rewrite. That goes double for SOP/SOG extensions.
>> 
>> Ommelettes and eggs...
>> 
>> Melanie
>> 
>> diva at metaverseink.com wrote:
>> > I have a question. How does this impact, if it does, extensions of
>> > SceneObjectGroup? For example, I have a traffic simulation where
>> > Vehicles extend SOG. How will this be affected? Will I be using
>> > components instead?
>> >
>> > Frisby, Adam wrote:
>> >> 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:* opensim-dev-bounces at lists.berlios.de
>> >> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Frisby,
>> Adam
>> >> *Sent:* Friday, 11 December 2009 3:48 AM
>> >> *To:* opensim-dev at lists.berlios.de
>> >> *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
>> >> 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
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 