Hi Terry, I've been thinking about your use of osg::findDataFile() in the archive handle segment of Registry::read(ReadFunctor&) and your related mods to osg::findFileInPath(..) and am starting to feel that it's not an ideal solution.
First up osg::findDataFile() and osg::findFileInPath() return a path to an file nested within an archive is only useful to code actually knows the path contains an archive and has special code to handle this instance - most code, such as found in the plugins, aren't archive aware - they just read raw files, and if they attempt to read a file nested within an archive they will just return an error on attempting to open the supposed file. As far as can tell the only code that is properly archive aware are the plugins like osga and zip that directly support archives, and the Registry::read(const ReadFunctor&) method. Is that the only place that the can take advantage of your changes to osg::findFileInPath() are the ones to Registry::read(const ReadFunctor&)? If so then pushing the archive searching into the general file search path is inappropriate. Couple this with the redundancy of search for archive nested files in the general search path that the scheme you implemented has I can't help but feel perhaps you are trying to co-opt other code too much for the support of archives. My gut feeling is that we should probably separate out the searching within archives to a separate method that is only called by those wanting to search in archives and that only searches for the archives in the file path lists and the cached archives. This specialist method would then be called by the read(ReadFunctor&). Thoughts? Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
