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.
