You ask hard questions :) My fundamental goal is to have archive names in a FilePathList treated *exactly* like directory names in a FilePathList. This seems reasonable to me because there is no conceptual difference between an archive and a directory. First of all, do you agree this is a good goal? If so, some of my changes fall out of that goal easily, while some probably have alternatives.
As far as I can tell, findFileInPath() is the one place in OSG where FilePathLists are searched for files. My extension to this function allows the contents of a FilePathList to be thoroughly searched even if they contain an archive name. I think this extension is appropriate and necessary to achieve the goal. > I'm not happy with a general file search being done when it's only the > file paths that contain a reference to an archive that we are > interested in - this is why I string out the search to just the > Options::DatabaseFilePathList. You are correct that this misses > searching the Registry::DataFileList and trying simplifications to the > name. I will have a think about this aspect. > I can see how this one would bother you. There is probably some redundancy happening here. I don't see a better place in the code to try to locate a file than right before you read it. Now that I think of it, I don't see one clear place where files are searched for. Is there one? Where does this happen normally? > > 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&)? > The only code I found that already handled paths with nested archives is at the top of Registry::read(const ReadFunctor& readFunctor), so I just extended it to be more flexible. This is pretty reasonable, but there still may be other ways to accomplish this. This is the same problem I was asking about above: if you want to send an exact path to Registry::read(), where is this path generated? findDataFile() would have to get called somewhere before Registry::read() so that the existing code that handles nested archive names would work. I agree plugins should never need to be archive-aware. I thought that was the main reason they contained dual read functions, one for a filename and one for an istream. If Registry and the archive plugins generalize things properly, then they will just feed the right archived data to a plugin's istream reader. > 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&). > You could separate directory searches and archive searches by allowing the user to set an OSG_FILE_ARCHIVE environment variable similar to OSG_FILE_PATH. This seems like an overcomplication to me since directories and archives are conceptually the same. This would only make sense if there were places in OSG where these lists weren't treated the same way, but it seems to me you would always be searching both of them at the same time. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
