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" <a...@deepthink.com.au>
To: "opensim-dev@lists.berlios.de" <opensim-dev@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-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Frisby, Adam
Sent: Friday, 11 December 2009 3:48 AM
To: opensim-dev@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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
