[Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

[Melanie]

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
> 
>