Hi Robert and Ulrich, Just for bit of history, the reason that I originally submitted those changes was actually for a project that is doing some streaming video using DirectShow where I wanted to pass in the URL to DirectShow so it could stream it rather than have the CURL plugin try to download the file and pass it to a stream based loader. After working with that a bit, it did become very useful in osgEarth as we were caching some objects based on the filename of the .earth file, which made integrating the CURL support by overriding the stream loaders awkward since you won't be passed the actual filename.
My workaround in both projects was to add a prefix to the server based URL's like "server:http://www.server.com/test.earth";. This caused the CURL plugin to be bypassed b/c it didn't realize it was a URL and the Earth plugin could investigate it, remove the prefix and download the .earth file itself. osgEarth has changed since then and the objects aren't cached based on the map filename any longer, so I believe it would be easier to implement loading from a stream. I still think it is very useful to let plugins have the first chance at dealing with all filenames rather than assume the CURL plugin should be used for all server requests so that you have more flexibility especially when integrating with 3rd party libs that handle all the fun networking stuff for you :) It makes sense to me that if the filename contain's a server path that no local searching should be done within the OSG_FILE_PATH. Would that just be a simple check in osgDB:;findDataFile to simply return the filename if the incoming file is a URL or is there more places that need tweaking? Thanks, Jason On Thu, Jun 4, 2009 at 12:55 PM, Ulrich Hertlein <[email protected]>wrote: > Hi Robert, > > On 4/6/09 6:26 PM, Robert Osfield wrote: > >> 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. >> > > Ah, so for things like http://www.foo.com/flat.earth you mean? Or do they > need to be > called for things like .ive and .png as well? > (It works for local files.) > > 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. >> > > Yes, I was thinking the same thing: > if (url) { > find plugin that supports the given protocol and the given extension > if (found) { > try that plugin > } > if (failed) { > try curl > } > } else { > > find plugin for given extension > do filename/filepath magic with that plugin > } > > The problem is that the stripping of the filepath is done before the >> libcurl plugin >> gets a lookin, so the file gets found locally. >> ... >> 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. >> > > Yes, this is why I moved the CURL test before the rest of the plugins. > But I agree that these two cases (URL vs. local file) shouldn't be both > tested at all. > > If it's a remote file and no one is able to handle it it doesn't make sense > to try locally - even if a file is found it's probably not the right one. > > Cheers > /ulrich > > _______________________________________________ > 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
