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