Hi Wang, On Thu, Jan 21, 2010 at 5:43 AM, Wang Rui <[email protected]> wrote: > I've made some fixes to the osgDB headers and sources, to make sure > they could be built under Windows and the visual studio. I've also > merge the osg2/ObjectRegistry with the osgDB/Registry class, adding > the add/remove/findWrapper() and add/remove/findCompressor() functions > to the latter, to be consistent with the implementation of > DotOSGWrapper's mechanism. > > Please review the attached headers and sources first and let me know > if they could be accepted.
I've just merged the addition of the exports for for now I haven't merged the integration of ObjectRegistry into osgDB::Registry as I'd prefer to keep it decoupled. The way I'd like to go with both DotOsgWrappers and the new wrappers is to have a dedicated container class for each of these that is attached to osgDB::Registry, so Registry "has a" wrapper container, rather than "is a" wrapper container. Once this is done it'll be easier to switch off the DotOsgWrappers, or make ammendments as the changes will all be self contained. I will have a bash at this later. > I agree that the Input/Output headers should still be used in a > parallel, because many other plugins depend on them. It's actually only a deprecated-dotosg wrappers and any 3rd party NodeKits that use them. The deprecated-dotosg we can amended easily, the 3rd party NodeKits we want to migrate across to providing the new type of wrappers. > Maybe we could > find a better way to replace them step by step. A good idea in my mind > is to find a way to merge Output and OutputStream together, so do > Input and InputStream headers. This may cause significant renaming and > modifying of the wrapper classes and the plugins, but should be worth > to be done. I'm in two minds about merging Output and OutputStream. How much overlap do you see? My main concern would be avoiding one huge class that tries to do too many different tasks. Renaming isn't too difficult, a quick sed script can tackle renaming pretty easily. > >> One thing of note that I would like to change about the new >> wrappers/readerwriter is that C++ exception support on embedded >> platform is available but not recommend for the cost it brings in >> execution size. This has lead me to avoid using exceptions in all the >> core OSG components, including .osg and .ive plugins. > > A not very serious problem here is how to actually 'throw' exceptions > using a common throwException() function like the ive plugin does. > That is to say, how to stop reading/writing immediately if there are > fatal errors. Otherwise users may meet an application crash, which is > unfriendly and tiresome sometime. The how stop to reading/writing is something that is very conviniently solved by exceptions, without them you have to set a flag and then check it periodically to see if one should keep working on the task. One can use whether an exceptions has been set as to whether one should stop reading/writing. > I'd like to start writing other core osg class wrappers, such like > osgText, osgParticle and so on. After that, we could announce this new > feature on osg-users and call for public tests and suggestions. I > expect these would be finished next week. Once we have one or two NodeKits wrapped we should be able to get the community involved to help complete the rest. The first NodeKit will be the most awkward one as it'll require a mechanism for automatically loading the required osdb_serializer_* plugin to get the wrappers. The DotOsgWrappers have this mechanism already so you can have a look at how this is done. Robert. > BTW: I live with my parents at present, but I'm sure to have a family > with my fiancee in the near future. :) Exciting times ahead then ;-) The OSG project got a bit of boost in it's infancy at the same time as the arrival of my first child. My wife and daughter would sleep during the day, rise late, go to bed early, for the first few months so I'd be left alone, awake but enable to head out and do my usual venture sports - so I just tinkered with code for fun instead. It's funny how the OSG and my eldest daughter have grown in parallel. I must be said she got to 1.0 much quicker than the OSG ;-) Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
