[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Tue Dec 15 16:39:36 UTC 2009

Yeah, I'm not worried about the refactorings. As long as what can be 
done now can be done after, too, hopefully even better. SOG/SOP need love.

Melanie wrote:
> 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
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 