Hi Wang Rui, Sorry for the delay in getting to review your prosed binary format plugin - I've been trying to clear the rather length backlog of submissions and bugs... I'm pretty near back ontop of things again and so look at the next steps beyond the OSG-2.9.6 dev release - and towards OSG-3.x.
For the purposes of the discussion I'll just use your initial .bin extension to denote the new plugin, this extensions isn't suitalbe to role out as part of the OSG as it's has other established meanings, but I don't think the naming of extension is critical at this point in time - we'll just need to settle upon the extension when it comes to making the next stable release. So... given this I'll now dive into my thoughts: First up, the plugin on first review looks a lot cleaner and flexible than the present .ive plugin and is certainly a worthy replacement for it, and would suggest aiming to make this new binary plugin or a derivative from it the main binary format for OSG-3.x. Second up, the format/implementation looks capable of being backwards compatible, and possible forwards compatible in a limited way. For instance I would guess that we'd be able to handle files that the plugin doesn't know about if the new additions are only in the form of classes that it doesn't already know about. It doesn't look like it'd be able to handle changes such as removal, additions to or refactoring of the classes that the old plugin supports and the new more modern file provides in a modified way. It would be very cool if we could achieve the ability to handle this. Perhaps having individual versions of wrappers for each class could achieve this. My third observation is that providing a dual ascii + binary format/parser wouldn't be possible right now as the .bin format/plugin as it stands implicitly reads/writes properties of each class - they have can only be successfully read if the properties are arranged in a specific order. To enable ascii support one would have to add a property name as an identifier when reading properties. However, one could do this and just ignore it for binary formats. Perhaps another possibility would be treat each property as something that should be wrapped, with class wrappers aggregating the individual property wrappers. Forth thought is that in terms of on maintenance of multiple native formats it's already a bit of pain trying to keep the .osg and .ive plugins up to date, consistent and bug free. Adding another hand maintained format to these will just make the whole process even more problematic. Replacing .ive with .bin would improve things because .bin is simply a better approach with it's more decoupled and extensible design, but... even better would be to be able to replace both .osg and .ive with a further evolved .bin. -- So what steps next... runtime testing... adding support for one other NodeKit to test how the plugins can be extended at runtime. Perhaps the core of .bin could be integrated into osgDB like the current .osg parsing and have the wrappers provided by the osg, osgText, osgFX plugins in the same way as the present wrappers... just maintain the two sets of wrappers in side by side subdirectories from each of these plugins. Thoughts? Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
