Marcus Lindblom wrote: > Dirk Reiners wrote: > >> the problem is for it to figure out what else to download. I don't have >> a good, general solution for that, unless it is used to open the file. >> >> > Are you trying to be able download everything including referenced file > before starting the parse? Or am I not understanding you correctly? > > If not, why not just override every referenced file-lookup and provide > the context (the location of the 'top' file) . Perhaps the context > should arrive with the istream, so that a loader can change the > context/base-URL if it wants to? > > Ah, you want to handle each load request with a single istream ?? I would try to open istreams on a per file basis. The istreamhandler just gets the request to access the file with locator "http://test/test.wrl";. This has some overhead to open a http connection to the same server perhaps several times, if several files are accessed. But to optimize for this, is the task of the istreamhandler. >>> [snip] >>> I do not know if it is worth it to redirect or to emulate plain Cs FILE* >>> behaviour (like downloading >>> the required file to a local temporary and then open as a FILE* ..). >>> Without a virtual file system approach those loaders would always >>> require modification. >>> >>> >>> >> I think it should work easily for all the image loaders. Either we >> change them to iostream (HDR), or they have facilities to read from >> abstract data source anyway (JPG, PNG). We can probably cover/convert >> all the stuff that we have in FileIO like 3DS relatively well. Where we >> get into trouble are things that use external libraries for loading, >> like Inventor or Performer. But for those I don't think there is >> anything we can do, but it might make sense to have a fallback mechanism >> that at least downloads the main file and runs the loader on it. >> >> > Doesn't all loaders use iostreams anyway today? I belive it was changed > in 1 a while ago. > > I forgot that the image loaders are mostly C libraries. Could that be changed to iostreams, does somebody know that? > Since we were discussion a file-cache also... wouldn't that might > provide a good solution to external libraries which can only load from a > local file? > Do you mean by a file-cache, something that copies all accessed files to local files. Webbrowsers are configurable in how many local file space they use, right? I would prefer to handle remote accesses by least possible impact of local storage. Perhaps only by request, it should be possible to write a local copy of all accessed files.. >>> With istreams it seems easier. The library boost.asio pointed out by >>> Allen seems to fit in nicely here >>> with boost.iostreams. >>> I need to get some practice with it. >>> Currently, there are some loaders which open additional streams during >>> loading besides the one passed in. >>> >>> >>> >> Only the model loaders, and for those I don't see away around it, honestly. >> >> > But there's no conflict in allowing that, is there, as long as they use > the right framework? > Yes, I think so. Changes are minimal then, but they are necessary ..
Christoph ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
