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 >>>> [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
