Which leads to the discussion we had a while ago. I'm still a proponent of having just ONE class, and let every object contain a group if it wants to, a very basic prerequisite for hierarchical linking. Inventory is already a class for itself, it just needs to be refactored to be largely self-contained. Scripts are a function of inventory, but separate. Geometry (shape) is already a class, but also too tightly coupled. Shape, Inventory, etc, should be largely independent and optional.
Melanie Sean Dague wrote: > Disclaimer: I'm not looking to implement any of this, at least not any > time soon. This is just food for thought, and I'm curious what others > think about these approaches. > > I've been recently thinking a lot about SceneObjects, and how they might > be made both more sensible, and more flexible, as today the SOG/SOP > stuff is very monolythic. > > It started to occur to me that SceneObjects are really a set of > capabilities. Some of the capabilities seem to be the following: > > * have physics applied > * be scripted > * be persisted > * be seen by all clients > * have inventory > * have children > * be modified by the client > > This isn't really an entire list, but it's based on times a SOG/SOP > interacts with classes beyond itself. > > Today we handle this with having all this functionality in a single > class, and then use bits or booleans or the permission manager to block > the system from doing certain things. > > While this works well enough in the SL use case, the moment you start > looking at creating objects through a path other than the Client > interfaces, you quickly start running into creating a lot of work > arounds to trick OpenSim into not letting these subsystems get their > hands on the objects (for either simplicity or performance reasons). > > Discussion is welcome, as I'm start to experiment on the synthetic > object side and it definitely exposes a new way of thinking about objects. > > -Sean > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
