Hi Gregoire, Sukender, and everyone, While writing this email, I have come to the conclusion that I/we do not really have anything (more) to be concerned about with tying user data and description list to the meta-data system. If you are interested in some of the concerns I already had, and that were further clarified while reviewing the proposed meta-data system, read on. I appreciate the responses I have received thus far. Again, thanks for all the hard work! :-)
...here is what I was thinking... My concern is not so much that the underlying structure will be unavailable, per se. It is that userData and descriptionList will now be tied to the meta-data system, with no built in alternatives. With the proposed implementation, replacing an existing meta-data container would effectively "clear" any existing userData or descriptionList. Further, if the special hooks for exotic types are part of the container, and that container is not written to handle generic data such as userData and descriptionList, use of userData/descriptionList may cause problems. Really, I am just trying to make sure I/we understand all the implications of tying userData, descriptionList, and meta-data together in the same core feature. Here is one problem scenario that I have some concern about: [code] // load some data osg::Node* p = osgDB::readNodeFile ( ... ); ... p->addDescription ( ... ); ... // if the following "third party" function calls setValueContainer, // this destroys any existing userData and/or descriptionList thirdParty::doSomeWork ( p ); [/code] In my project, we have been using descriptionList as a work-around to userData and the fact that each osg::Node is restricted to not more than one attached instance of userData. I did not want to interfere with any existing userData generated by geometry and scene files, so I used descriptionList to store our runtime data, because descriptionList appears to have no explicit restrictions beyond that of a std::vector. If a "third party function" happens to cause the description list to be cleared after we have added some data to it, we would lose the data we need to do some of our runtime work. In reality, the proposed meta-data system does not cause the above problem scenario; the problem has always been there (the third part function could have directly called setDescriptions). However, this is one more way to "clear" the description list. I suppose, in the end, there really is no need for my concern. You propose (or I have inferred) a required interface with specific guaranteed behavior for writing custom containers; if container providers follow the rules, userData and descriptionList (or whatever a client may want to use) will still be supported. As long as no one takes the opportunity to replace an existing meta-data container without documenting that this is what they are doing, we should be fine. I will review version 5 of your document, and I will give myself some more time to digest what you have written. I already like what I have seen, and the more that I think about it, the better understanding I have of the developing situation. Thanks, again... D.J. On Mon, May 2, 2011 at 10:05 AM, Sukender <suky0...@free.fr> wrote: > Hi D.J., hi all, > > Here is the v5 update! Not a huge thing but we modified it according to our > experiments. Check out the "[v5]" tags in the document. > > @DJ: Well, as Gregroire said, the methods are always here to access > userData and desriptionList, but you cannot access the members directly, as > they disapeared. In core OSG, we spotted that there were very few direct > accesses. Do you fear this would not be the same for OSG users? > > @Gregoire: On the right path you are, padawan! ;) > > Sukender > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > > ----- "Gregoire Tarizzo" <gregoire.tari...@virtuelcity.com> a écrit : > > > Hi D.J. , hi all, > > > > First, thanks a lot to all, for your feedback and ideas. I’ve been > > following with a lot of interest your ideas and propositions on this > > topic and it helped us a lot. The v5 of the documentation will be out > > soon (likely monday), with more detailed information and the latest > > changes we made in our implementation. > > > > > > @D.J. About the deprecation of _userData and _descriptions : > > Well yes, this behaviour is intended. One of the objectives of this > > meta-data system was to replace _userData and _descriptions from the > > object and node and by doing so, make it a few bytes lighter when not > > using any of those, while providing a tool able to handle multiple > > values from multiple types. > > Moreover _userData and _descriptions may be removed, but it doesn’t > > mean that all the _userData and _descriptions methods won’t work > > anymore. We reforged them so that they use the new metadata system. So > > hopefully it won’t change anything for the user. One of our first > > issues was the “protected” access to _userData, meaning we can’t reach > > the 100% backward compatibility if we delete _userData because of the > > possibility of a direct access to this member w/ using the getter. > > In the end, we thought that the side effect is not major enough, and > > easy to deal with (juste replace the direct _userData accesses in > > Object derived classes by the getUserData() method, and it works > > fine). > > > > > > 1st post on this mailing list/forum, yay. \o/ > > Regards, > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
