Another thought that might make this cleaner:
We could add a value to the ReaderWriter::ReadResult enum such as
"FILE_FOUND_IN_ARCHIVE" -- plugins would return this value if findDataFile()
located the file in an archive. Then Registry would act on this return
status. This would remove the recursive element, making the flow cleaner.
Each plugin would simply need a statement like:
if ( osgDB::isValidArchivePath(fileName) )
return ReadResult::FILE_FOUND_IN_ARCHIVE;
Glenn
On Jan 22, 2008 11:55 AM, Glenn Waldron <[EMAIL PROTECTED]> wrote:
> Robert,
> Following your lead, here is a second take on this. See what you think of
> this approach.
>
> We add the following to FileUtils:
>
> findFileInArchive() -- called by findDataFile() and returns an "archive
> path" e.g. archive.osga/file.jpg
> isValidArchivePath() -- returns true if the input parameter is an
> "archive path" as defined above (and the archive exists)
>
> Then we expose the archive extensions list in Registry:
>
> getArchiveExtensionList()
>
> Finally, each plugin simply checks the file name returned from
> findDataFile(), and if it's an archive path, it redirects control back to
> the registry (which can already handle archive paths correctly).
>
> I have attached this prototype solution -- it is tested and works with
> JPEG -- and would be easy to apply to most other plugins.
> Let me know if this makes more sense.
>
> Thanks again for taking the time on this - Glenn
>
>
>
> On Jan 22, 2008 4:03 AM, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> > Hi Glen,
> >
> > On Jan 22, 2008 1:59 AM, Glenn Waldron <[EMAIL PROTECTED]> wrote:
> > > OK understood - I agree that it's not the most elegant solution - in
> > any
> > > case I think I can work around it n the meantime by referencing the
> > full
> > > archive path in the texture def ( e.g. archive.osga/texture.jpg).
> >
> > I do wonder if the findFileInPath is where the action should be - as
> > this is in affect what we are doing here. Prehaps we could have
> > findFIleInPath, a findFIleInArchives, find FileInArchivesOrPaths type
> > of thing. Perhaps if we change the findFileInPath just to be aware of
> > archives so that it becomes it checks them. The findFileInPath would
> > be a convenient mechanism as it could is encapsulated and fits with
> > concept that an archive can be treated as a directory.
> >
> > The findFileInPath route would pass back a filename that includes the
> > archive name, and something that can only be opened the archives, and
> > not by the plugins that actually call findFileInPath, so that plugins
> > themselves would need to be tweaked a little so that they can support
> > reading from an archive path.
> >
> > > I will work on this and submit it separately. Thanks -gw
> >
> > Thanks.
> > _______________________________________________
> > osg-submissions mailing list
> > [email protected]
> >
> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >
>
>
>
> --
>
> Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791
>
>
--
Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
