Hi Wang Rui, On Sun, Jan 17, 2010 at 2:00 PM, Wang Rui <[email protected]> wrote: >> 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. :)
I'll put this in place then. I'll refactor you plugin and the OSG wrappers etc. >> 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? I'd prefer to wrap them all into a single plugin, including optional backwards compatibility with .osg. We can do the later with low cost because we all we need is the high levels hooks to osgDB::Input/osgDB::Output, all the wrappers will be put out into their own sub-directory within src/osgWrappers/dotosg. Having a single plugin we ease maintenance and make it easier to dynamically decide what version of the .osg file that file is being loaded. It will also lead to a smaller footprint on disk as the less will be less plugins sitting on disk, and also small footprint in memory if you are loading .osg and .osgb files as again only one plugin will be loaded. For static builds I think it'd also help as there wouldn't be any confusion about trying to include symbols from the wrappers twice. > >> 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? Possibly, but this would break backwards compatibility for users currently implementing .osg wrappers. It would also require us to export symbols from the plugins, and have a .lib and .dll under windows, whereas normal OSG plugins deliberately don't export any sybmols and just have .dll's. My inclination right now is to partially break backwards compatibility in the cause of keeping it clear what is what. The way I'm thinking of doing it is placing all the old DotOsgWrappers/Input/Output classes into a single DeprecatedWrappers/DeprecatedIO header, or moving the deprecated headers into the src/osgDB directory but still include them in the exports of osgDB. For the time being I'd keep all of the deprecated headers in place, get the new plugin working and then we get the community testing things. > > 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. I'm not familiar with technique. My main concern about random access support is that when reading from sources such as http one doesn't have the luxury of random access. Other istream sources don't have random access. I don't know how what you are suggesting fits in with this, personally I'd like to keep things simple. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
