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-boun...@lists.berlios.de [mailto:opensim-dev- >>> boun...@lists.berlios.de] On Behalf Of Melanie >>> Sent: Tuesday, 15 December 2009 8:05 AM >>> To: d...@metaverseink.com; opensim-dev@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 >>> >>> d...@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-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 >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev