Hi Paul, On Sat, Jun 13, 2009 at 4:04 PM, Paul Martz<[email protected]> wrote: > Hi Robert -- If you don't see this as an issue that merits a mod to osgDB, > then I will not pursue the issue and will not submit a change. (Giving this > some thought overnight, it seems like I can provide a solution to my clients > in a middleware library that avoids mods to the app and also avoids changing > osgDB.)
It does require a middleware library, one could easily just write a custom Regisytr::ReadFileCallback to a load of plugins according to which one you think might be appropriate. > Extension string conflicts do occur. I have encountered this issue in work > I've done for my clients. Both my client and I have agreed that it rather > defeats the purpose of the plugin system to have to explicitly preload a > plugin, but so far that is the solution we've employed. I would not say the need for preloading in certain circumstances defeats the purpose of the plugin system, rather it shows the flexibility of the plugin system to allow unusually usage patterns. > So the stimulus for this current thread is to avoid the situation in the > future, as I create plugins that use rather generic-sounding extensions like > ".osgb", ".skel", and ".skeleton". It only become a problem is multiple users tried to submit separate plugins to the core OSG that used the same extension. While the duplication is in separate user applications or libraries it doesn't affect other OSG users. > Recently, someone posted a submission to OSG to load point cloud data in a > plugin using the extension ".txt". This seemed ripe with potential for > extension string collisions; I believe I (and others) steered him away from > that extension, not sure what the outcome was. The resolution was to generalise the existing .3dc point cloud plugin to handle the format that were using. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
