Hi, before I log a bug, just checking here if I did a mistake or if there's a way to handle this case:
When fetching files using both EMSCRIPTEN_FETCH_LOAD_TO_MEMORY and EMSCRIPTEN_FETCH_PERSIST_FILE flags at once, it seems fetch will execute onsuccess callback even if the persist file failed. This happens when fetching a file too large to write in IndexedDB (which happens often in Chrome, since apparently they set a limit on the file size allowed in IndexedDB) while the XHR to memory was successful. Would that be considered a bug in emscripten fetch? What can I do on my side to properly handle this? Preferably we don't need to re-fetch every file with EMSCRIPTEN_FETCH_NO_DOWNLOAD to verify if they were correctly written to IndexedDB? Thanks! On Wednesday, March 8, 2017 at 8:41:04 AM UTC-5, jj wrote: > > 2017-02-24 12:31 GMT-08:00 Robert Goulet <[email protected] > <javascript:>>: > >> However this pose the problem that if the content changed on the remote, >> the local storage will be used instead of the newer remote content. I was >> hoping there would be a way to compare remote file timestamps with local >> storage file timestamp, and replace local storage if remote file timestamp >> is newer, but I couldn't find it. >> > > This is a TODO I have, my thinking was that there could be an attribute > flag EMSCRIPTEN_FETCH_DOWNLOAD_IF_NEWER that would still perform an XHR and > get back a 304 Not Modified if the copy in IndexedDB was up to date. Iirc > there was a discussion thread about this earlier on emscripten-discuss when > the fetch API was being circulated for review. A second related request is > to support content ETags, which is also on the radar. > > >> Should I be implementing my own versioning system somehow? A timestamp >> based system would have been nice because it would allow to replace single >> files instead of all files. Should I look into implementing a timestamp >> replace option in Emscripten fetch API, or should this entire versioning >> system stay outside of the API? >> > > Definitely if you have some kind of "higher level" understanding in game > code to deduce which assets may need updating, that kind of versioning will > always be superior in performance compared to a fine-grained timestamp > based scheme at individual file level. This is because if your assets are > mostly immutable/nonchanging and doing timestamps, each IndexedDB file read > will still incur a XHR to remote server to get back that 304 Not Modified, > which can be a lot of redundant pings if there are lots of files. Currently > if a XHR is cached to IndexedDB, there are no XHRs performed at all to > remotes when loading the file, which is very fast. Therefore if you have a > higher level scheme that you can employ, it will always be more efficient > than individual file level. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
