[Opensim-dev] custom scene data (Re: [Proposal] Separate SceneObjectGroup/Part into separate classes/interfaces)

[Toni Alatalo]

Justin Clark-Casey kirjoitti:
>> One issue we have is the Opensim scene object data model. For the viewer 
>> side, we designed and implemented an Entity-Component model in spring - 
>>     
> Out of interest, have you thought about a Model-View-Controller approach to this problem?
>   

AFAIK not explicitly. It's possible though that the people who did the 
research in January (Tuomo Korva IIRC) considered it. Am not sure what 
exactly it would mean together with the model we have. One key thing in 
the E-C model is that it's all just data, no functionality.

MVC-like issues may become current here now that work on GUI tools is 
approaching. For example in the little test object editing/placement 
widget I did on friday one thing I didn't implement yet is having the 
gui widget state update when the object being edited is simultaneosly 
changed by someone/something else on the server. The network connection 
and the GUI tool being kind of two controllers to the same data. In the 
current viewer code that'll work by the gui component also registering 
to scene events so it can handle updates from elsewhere to the object 
it's modifying.

> Personally, I think that we should support arbitrary data directly but I know other core developers have concerns about this (such as performance ones).  This is probably a topic for debate.
>   

Obviously everyone wants and needs good performance too, hopefully both 
can be achieved acceptably with a good design.

> I think it would be fantastic if Realxtend could help lead the way on a SOG/SOP refactor in partnership with the other interested devs.  The best thing would be to develop a roadmap in co-operation rather than wait for one to happen.  The topic of SOG/SOP refactoring has been kicked

Ok, thanks for the feedback.

We haven't discussed this much here yet, and it's not urgent just yet - 
easily enough work still on the client side for now. We have a planning 
session next week, and will probably discuss before that whether 
something related to this should be prepared now or postponed yet 
another month or more.

If anyone else is ready to have a go with some refactoring there, don't 
wait for us now - if we start something soonish I bet it will be with 
tests and planning, like you said a roadmap, and not immediately jumping 
to modify the current codebase.

~Toni

>  around before in this mailing list - not just this time - but no-one has had the resources to go forward with it.
>
>   
>>> 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......
>>>   
>>>       
>> So in our design the base Entity is so minimal that it doesn't have any 
>> data, just an identity with pointers to mostly minimal data components 
>> like Placeable for pos&rot&scale, and larger data like Prim. No 
>> interfaces are used, but the extensibility is achieved by aggregation.
>>
>>     
>>> Melanie
>>>   
>>>       
>> ~Toni
>>
>>     
>>> 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
>>>>     
>>>>         
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>   
>>>       
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>     
>
>
>