[Opensim-dev] [Proposal] Separate SceneObjectGroup/Part into separate classes/interfaces

[Melanie]

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 at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev