Hi Wang Rui, I've been thinking about directory structure and currently thinking that perhaps we should move all the different types of wrappers into the src/osgWrapper directory within a series of subdirectory thus:
src/osgWrappers/introspection/ - all the original contents of osgWrappers, just nested src/osgWrappers/serialization/ - the new style wrappers src/osgWrappers/dotosg/ - the old style wrappers (or perhaps just called deprecated) In the normal plugins directory we have: src/osgPlugins/osg - handles both new and deprecated ascii formats? src/osgPlugins/osgb - binary format The combined osg plugin could automatically detect which version to use by parsing the first line, and then dynamically load the wrappers from the serialization or deprecated/dotosg set. In the case of statically built applications we'd need to static link in both the plugin and appropriate wrappers, and the app developr can choose which set of serialization of deprecated/dotosg set they link in. A single file with a C entry point could list all the wrappers in each of the wrapper libraries to make sure that all the parts are pulled in. Potentially would could generate this file automatically by running a dynamically built app and getting all the wrappers, or load a set of .osg/.osgb files and then generate a source file that pulls in all the required symbols. The later approach is something that users in embedded space might find useful to keep down the cost of IO. All this static stuff can be handled later so don't worry about it right now. The above approach requires us to keep the the old DotOsgWrapper infrastructure in osgDB alongside the new infrastructure that you've developed. At a later date we should we should be able to move it out of the core OSG completely into a deprecated project of it's own. Thoughts? Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
