[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

[Ryan McDougall]

I think it's a good idea! Where can I sign up?

Cheers,

On Tue, Dec 15, 2009 at 7:12 PM, Charles Krinke <cfk at pacbell.net> wrote:
> Dear Adam:
>
> This seems like a good idea as all of your ideas are and I support it. Lets
> move forward.
>
> Perhaps one way to move forward is to help to encourage patches that meet
> this vision. I am thinking of an example with notes and TODO so that others
> can take the example subroutine and add patches to follow your vision.
>
> Charles
>
> ________________________________
> From: "Frisby, Adam" <adam at deepthink.com.au>
> To: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
> Sent: Tue, December 15, 2009 3:04:56 AM
> Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing
> Components
>
> 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
>
>