Hi Paul, On Wed, Dec 16, 2009 at 6:57 PM, Paul Martz <[email protected]> wrote: > As you know, I have a private nodekit that uses the .osgb extension. In > order to avoid collisions with the upcoming new OSG binary format, I've > added a static initializer to the nodekit to force load my .osgb plugin. As > we've discussed previously, this is what I need to do to avoid forcing > client apps to do this explicitly, right?
You don't need a static initializer, just preload in the main would be fine. Might I suggest not using an extension that is the same as .osg* extension as this would avoid the issue. I realize this will require a small amount of code + doc changes but it's only likely to be a couple of lines in both cases, and for modes that are already created you could use "osgconv -e osgb" option to convert them. > My nodekit depends on osgWorks, which contains a plugin that supports the > .skel extension. So, just to be safe and avoid possible future collisions > with the ".skel" extension, I also added a static initializer to osgWorks to > force loading the .skel plugin. > > The net effect is that whenever my .osgb plugin gets loaded, my osgWorks > .skel plugin also gets loaded. This is correct and expected behavior. Just how likely is a extension collision though... if you are careful about it collisions don't happen too often, and rarely for one particular sector, so one typically won't hit upon this issue. The .osgb case is very much the exception. > Unfortunately, this breaks "osgconv --format osgb". Issuing that command > incorrectly displays output for both my .osgb and .skel plugins. It should > display only output for the .osgb plugin. > > The root cause appears to be flawed login in osgDB::queryPlugin(). This > function is passed a plugin filename, which it loads, and then assumes that > any plugins that got loaded must be appropriate to query. This is a false > assumption in the presence of static initializers, as I describe above. Plugins can legally have multiple reader writers in them, and the whole readerwriter design is to be as decoupled as possible - this allows you to stick ReaderWriters in the main application, in a plugin that is dynamically loaded, or statically initialized... lots of different combinations. The queryPlugin() method has come a long time after the basics of osgDB and the plugins were put in place, and is designed to be a helper function that works well enough to get useful info out. If it doesn't always pick out the right information with unusually plugin combinations then this is unfortunate. The queryPlugin is not critical functionality though, it's something that osgconv uses for a bit of extra info, for normal OSG usage it'll be used very rarely. > My personal preference would be to enhance Registry to handle multiple > plugins that support multiple formats with the same extension, thus avoiding > the need to preload plugins, as I have mentioned in other posts. But if this > is still off the table, Having multiple plugins per extension supported in osgDB::Registry will complicate and already complicated set of codes. It's already hard enough to maintain and understand as it is, adding extra complexity would really have to be justified by something that effects all users, and in way that doesn't have any other solutions. In the case of multiple plugins per extension I just do see this strong need, we've gone a decade without absolutely needing it, the OSG has many thousands of users and they haven't been stumbling over this issue. There is also a solution - preloading for those who have the niche need of having multiple plugins per extension. Pre loading is one one line of code in an application - it's not complicated, hard to implement or maintain. Does removing this one line of code from an application of a small number of users justification for adding complexity into osgDB? For me it's a no brainer for me, the OSG is already complicated enough as it is, and there always the pressure from the community to add extra functionality and complexity, so keep to things manageable my role these days is largely about spotting ways to simplify or avoid further complication of the code base but retain the flexibility and functionality of it. > then my fallback solution would be to change > pluginQuery so that it takes an extension as a parameter, and only queries a > loaded plugin if it accepts the extension. I guess one could add an extra extension parameter with a default of "" which would leave the behavior as it is now, and then when it's defined then use it to query the plugins loaded would work. > Do either of these sound acceptable? If so, let me know which one and I'll > code it up. The changes to pluginQuery seem like the more sensible and least intrusive approach. Yes it'll add complexity, but it's encapsulated within a single function so the opportunity for regressions and difficulties in maintenance are much less of a concern. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
