Hi Ulrich, On Thu, Jun 4, 2009 at 5:13 PM, Ulrich Hertlein <[email protected]> wrote: > Good point, I thought they only look at filenames like .earth
They do, but their plugin still hasn't be called first. > Could we iterate over all plugins that support the protocol in question, > with the CURL plugin being the last resort? This might be something that we could do to change the order to push filenames with protocols to be searched in plugins that support that protocol first. > Yeah, the joys of file path searches... > I agree that we have to check the basename of the filename, but probably > only after testing the full filename. > > So for "sub1/sub2/image.jpg" and a filepath of "aaa:bbb" we could check > sub1/sub2/image.jpg > sub2/image.jpg > aaa/sub1/sub2/image.jpg > bbb/sub1/sub2/image.jpg > aaa/sub2/image.jpg > bbb/sub2/image.jpg > aaa/image.jpg > bbb/image.jpg > image.jpg (maybe, or maybe only if the current directory is in the path) > > The last part I only mentioned because I believe the search path should have > preference over the local directory. If there's a file "image.jpg" and one > in "media/image.jpg" and I set the search path to "media" then I don't want > the local file to be used. This is actually what happens now, the filepath prefix of the file is not stripped for the initial file searches, only if this fails will the path be stripped then the naked filename tried on all the file paths. The problem is that the stripping of the filepath is done before the libcurl plugin gets a lookin, so the file gets found locally. >> To get round this problem I though perhaps we could add an exception to >> the file path >> search scheme that makes it reject trying to search for files that have a >> server path in them. > > I think that makes sense. If the filename is not local it doesn't make > sense to check plugins that only understand local files. The current search path mechanism actually only understand local files, it can't check remote files so one possible could interpret this at don't even attempt to do any searching. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
