Hi Robert, 2010/1/16 Robert Osfield <[email protected]>: > 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)
Yes, please. :) > In the normal plugins directory we have: > > src/osgPlugins/osg - handles both new and deprecated ascii formats? > src/osgPlugins/osgb - binary format At present, the ascii and format supports are combined together in the OutputStream and InputStream classes, with if/else judgements in their low-level streaming APIs. I'm also planning to add xml support in this way later. So, we could either have an osgPlugin/osg2 directory for dual or even treble formats support and an osgPlugins/osg for the deprecated ascii format, or have 4 sub-directories for osgt, osgb, osgx (xml support) and the old osg formats. The latter will be clearer to users (and maybe a little efficient because of omitting extra if/else judgements) but requires immediate modifications of current i/o stream and serialization classes. Which do you prefer? > 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. I totally agree your strategy for static link projects. But the existence of Output/Input and OutputStream/InputStream classes at the same time might cause confusions to developers, so do DotOsgWrapper and ObjectWrapper of the .osg2 format. Is it possible to move deprecated ones to their own plugin directory, and use a relative path while including header files? And for the topic of random access file i/o, the best implementation in my mind is to use file mapping, which maps a file's contents with a portion of the virtual address space and brings a great efficiency improvement and also huge file reading support. Maybe we could later implement a derived ifstream class (for instance, rewrites the osgDB::ifstream) to do this, which will be a direct benefit for all plugins and the xmlparser, without more coding work. The QSharedMemory class in Qt GUI will be a good example to solve the platform-dependent problems. Wang Rui _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
