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: [email protected] [mailto:opensim-dev- > [email protected]] On Behalf Of Melanie > Sent: Tuesday, 15 December 2009 8:05 AM > To: [email protected]; [email protected] > 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 > > [email protected] 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:* [email protected] > >> [mailto:[email protected]] *On Behalf Of *Frisby, > Adam > >> *Sent:* Friday, 11 December 2009 3:48 AM > >> *To:* [email protected] > >> *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 > >> [email protected] > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
