Hi Robert, 2010/1/15 Robert Osfield <[email protected]>: > > To help out with the migration to your new plugin I've moved the > include/osgDB/Serializer header out of the OSG and back into > VirtualPlanetBuilder where it was originally located. This move > insulates VPB from changes you've made to Serializer so we'll be able > adopt your version and not worry about accommodating the old usage > model, and not worry about breaking the VPB build. >
Thanks for your efforts. It makes things clear now. > > Another step I'm considering is refactoring the DotOsgWrapper could > out of osgDB::Registry and placing it in its own singleton class. > Thankfully apps use the the proxy singleton which hides the > registration implementation so we'll be able to make such changes > without breaking backwards compatibility. > > It might be that we'll want to have a OldDotOsgWrapperManager and > NewStyleWrapperManager as classes that the osgDB::Registry owns, the > NewStyleWrapperManger being just a place holder name for what your > osg2 plugins Registry class is. The osg2 plugin Registry class in fact mimics osgDB::Registry, and could be migrated to it soon as a series of member methods. I totally agree that we maintain a OldDotOsgWrapperManager and a new one (which manages osg2 plugin's ObjectWrapper instances). And users may choose to use the old mechanism to keep backward compatibility. > Another thought I'm playing with is where to place all the wrappers, > both old and new. For instance we could collect all the old .osg > related plugins together and place them in separate deprecated native > IO support sub directory, and then have the new wrappers in their own > sub-directories - a bit like what we have right now for > osgIntrospection's src/osgWrappers/ collection. Potentially we could > name these various plugins differently as well - such as > osgio_nodekitname as in your earlier suggestion. Yes, an src/osgIO subdirectory should be clear enough for reader/writer wrappers. :) The reason I'm thinking of reusing parts of the osgDB::Field* and osgDB::Input classes is, I had to seek backward with the input stream while reading ascii streams, for example, match property names (read some characters and compare, and then move the read-pointer back). I'm not sure if the std::istream::seekg() method is good enough without too much efficiency loss and excessive reading file operations. Maybe we could just do something with osgDB::istream and ostream classes to work efficiently. Wang Rui _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
