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
