Look at MRM.IObject - seriously. Adam
> -----Original Message----- > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > boun...@lists.berlios.de] On Behalf Of Melanie > Sent: Saturday, 18 July 2009 11:27 AM > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] [Proposal] Separate SceneObjectGroup/Part > into separate classes/interfaces > > A clear and loud +1 on getting started on removing this SOG/SOP > hierarchy thing. > The basic "node" could be stripped down to position, rotation, > scale, parent, children and a few more things, with the prim stuff > being in it's own class like Inventory was already moved out. > > Accessors for the common, and frequently used, things like inventory > would keep things moving at a manageable speed, so I'm also all for > that. > > I don't now about the interface registry, I'd rather see this > "minimal" class be a base class from which more specific classes > inherit and that handles the connections to Scene and the linking > stuff. Seems more sensible to make this most used entity be fast, > specific subclasses rather than registered interfaces. But... a > subclass could offer that registration method if it needs to be that > extensible...... > > Melanie > > MW wrote: > > Both SceneObjectGroup and Part are growing beyond manageable sizes > (with both of them over 3000 lines long), and are not very easy to > change when trying to make custom classes bassed on them (as I think > Sean found out recently during his attempts). > > > > Ideally I think we would all like to see the separate Group and Part > architecture replaced with a architecture that was more like a Node > based scenegraph , and had a hierarchy of SceneObjects. But I think we > all know of the problems in doing that, and how much work is involved. > > > > So as a small step in (hopefully) that direction, I propose to start > splitting those two classes up, and having something similar to the > interface registry we use in various of parts of the architecture. > (RegisterInterface<type> , RequestInterface<type>() ). > > > > So things like the methods for editing prims would move out into a > separate class; for example ISceneObjectGroupEditing. And then when the > scenegraph wants to call a editing method on a Group, it can call : > > > > Group.RequestInterface<ISceneObjectGroupEditing>(); > > > > > > I believe that this will at least make the code more manageable and > make those classes easier to customise. I also hope that it will make > it easier to head towards a new combined architecture for prim > handling. > > > > The draw back could be performance, as we will have the overhead of > calling those methods to request the correct interfaces. Although we > could do the same as we do in scene and have properties that can access > the common interfaces. (eg. SceneObjectGroup.Editor) > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > 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
