I think there is no need to do any work in the plugins. Registry::createLibraryNameForExtension(const std::string& ext) gives you the name of the library (plugin) you have to load having in mind all the aliases. And I like this design and I think it is ok
Nick http://www.linkedin.com/in/tnick Sent from Gümüşsuyu, İstanbul, Turkey On Tue, Dec 15, 2009 at 11:04 AM, Jan Pečiva <[email protected]> wrote: > Paul Martz wrote: > >> Thrall, Bryan wrote: >> >>> When you add an alias, though, aren't you saying to the plugin, "Trust >>> me, even though you don't recognize the file extension, handle it"? >>> >> Hi Bryan - Exactly! This is what I had on mind. If I tell the plugin: This > is MY alias, it should take my word and start to accept my extension. This > would be a very logical behaviour. > > Hi Bryan -- That might be what you're saying, but that's not how >> osgDB::Registry is interpreting it. :-) >> >> Without aliases at all, Registry forms plugin names from the file >> extension. If an app tries to load a *.gif file, Registry creates a plugin >> named "osgdb_gif.xx", tries to load it, then calls into it to load the *.gif >> file. >> >> Aliases tell Registry how to form the plugin name when an extension is in >> the alias list. A concrete example is OpenFlight. The Registry constructor >> registers "flt" as an alias to "OpenFlight". If the app tries to open a >> *.flt file, Registry finds "flt" in the alias list and knows that the plugin >> name is "osgdb_openflight.xx". >> >> Bottom line: When you register an alias, you're not talking to the plugin >> at all. You're talking to the Registry. >> > Yes, Registry interprets it currently in a different way. > > It would make sense, IMHO, for osgDB::Registry to add aliases to each >>> plugin's list of handled extensions, and I don't think that would take too >>> much work to do (make ReaderWriter::supportsExtension() public and call it >>> in getReaderWriterForExtension() when it gets to the loaded library). >>> >> >> Many plugins check the extension directly in ReadNode and return >> FILE_NOT_SUPPORTED if it doesn't match what they expect. What you suggest is >> possible, but would require you to check and possibly modify every single >> plugin, and every single read and write entry point in the plugin, to >> conform to the new behavior. >> > I think, the extension should be simple. The loading process needs just one > new step (step 3): > 1. form plugin name from extension (using aliases as well) > 2. load the plugin > 3. append new extensions to the plugin (taken from aliases) > 4. load the model > > Just step 3 is the new one. By using ReaderWriter::supportsExtension, we > should be able to tell plugin, accept even these extensions, because these > are your aliases. > All the rest of the loading process stays untouched. This way, we should be > able to achieve the extension overriding/aliasing without changes to all the > plugins. > > If this will be agreed that it is an interesting idea, I am going to take a > closer look on possibilities of implementing it. > John > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
