That's a good point. It's not a bug that download works, xhr fails and the result is a call to the success handler. However I think we should improve the API to report in the success handler that only the download succeeded, but not the IDB store. Would it work if there was a some parameter in the fetch attribute structure to signal that?
2017-03-09 20:09 GMT+02:00 Robert Goulet <[email protected]>: > 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]>: >> >>> 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. > -- 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.
