Terry, On equating archives and directories: Sometimes a zip file is just a general-purpose collection of data. But often an archive has certain semantics, namely that it is a self-contained and usually self-referential object.
KMZ is a good example. An archive created by VPB is a good example. An zip containing a FLT file and all its external refs is another. These archives have one reference point that's meant to be reached from outside the archive and then any internal references typically stay internal. A file inside an archive should never see a relative path resolve to something outside of the archive. Given that, maybe trying to represent both uses of archives with one class is an issue; technically two archives might both just be zip files, but semantically they differ for search path purposes. In osgEarth we addressed this by using a "referrer" concept so that a relative reference would always be relative to the referrer. It's like a search-path stack, if you will ... the current read operation only searches the path list on top of the stack. Once you're in the archive, the archive becomes you new search domain (for relative references). Glenn Waldron / @glennwaldron On Fri, Feb 3, 2012 at 1:31 PM, Terry Welsh <[email protected]> wrote: > 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 >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
