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

Reply via email to