> > > - Are you planning to add user pointer to emscripten_fetch_attr_t so that > we can pass it to the callbacks? >
Yeah, that is definitely a must to have feature, and it is already included, see https://github.com/juj/emscripten/blob/emscripten_fetch/system/include/emscripten/fetch.h#L53 . I haven't managed to document that yet, but will note to do that when completing the docs. > - What about caching? i.e. emscripten_fetch decides whether or not it > should do an XHR request or use IndexedDB data based on timestamp of the > file from the remote web server? > This is a good idea. The current protocol for IndexedDB-backed emscripten_fetch() is as follows: 1. Look at IndexedDB if URL/pathname exists. If it does, return that without doing any XHRs at all. 2. If the entry in IndexedDB does not exist, do the XHR and store it in IndexedDB. This is sufficient for scenarios where application manages its own IndexedDB data lifetime scheme. Even though the above protocol looks "cache-like", the intent or semantics of the IndexedDB storage are not to be a (transient) cache, but a permanent persistent storage. If an application would like to treat the storage as a transient cache, they should do so by managing old file eviction manually. I think I'll need to add some kind of API for enumerating files in the storage for that. For timestamp management, there's two ways: a) emscripten_fetch() supports passing any custom HTTP request headers, so it is possible to pass a Last-Modified-Since: header to the request from application code to manually do downloads only if newer than a given timestamp. The EMSCRIPTEN_FETCH_REPLACE flag can be paired to force replacing an old entry in IndexedDB if it exists. This allows applications to perform their own caching schemes if they want to do something complex. b) The above will be enough if the application knows the modified timestamps. The timestamps will be stored with the data in IndexedDB (in posix inode format). For convenience, I think it would be good to add a flag EMSCRIPTEN_FETCH_UPDATE_IF_MODIFIED, which would change the protocol to 1. Look at IndexedDB if URL/pathname exists. If it exists, read its modified timestamp. 2. Perform an XHR to download the data, with Last-Modified-Since: time be the timestamp if the datafile did exist. 3. If the XHR comes back with new modified data, update the entry in IndexedDB, otherwise return the original data file from IndexedDB. This would help applications not need to fire up a IndexedDB timestamp read first, but they could do updates in one fetch() request. Slightly related, c) Our existing IDBFS filesystem has a whole mount point covering version number string, where a built application can set a version for the cache, and application rebuilds can bump up the number of this cache to invalidate everything existing in the storage. I'm thinking that something similar overarching could be also useful here so that application rebuilds have a scheme where they can nuke all old files if needed. -- 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
