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: [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 > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
