It's safe to do so, the method creates a copy, https://github.com/kripken/emscripten/blob/master/src/library_idbstore.js#L24
I think the answer to the second question is no. Unless someone wrote a tool to read a specific browser's IndexedDB storage. But in general, there is no spec for how that is stored, there is only a spec for how using IndexedDB inside the browser. I suppose a tool could be written though that opens a browser, reads the file from IndexedDB, and saves it somewhere, all automatically, as a way to read from IndexedDB. On Fri, Oct 16, 2015 at 9:41 AM, Robert Goulet <robert.gou...@autodesk.com> wrote: > Regarding the emscripten_idb_async_store function, can we safely free the > memory passed to this function or does it need to exist until either store > or error callbacks are called? > > And if I need to get the content I wrote using this IndexedDB system, is > there a way to get it outside the web browser? For instance, say I'm > creating a screenshot in PNG format, and want to write it on disk, and use > it elsewhere, is it possible with IndexedDB? > > On Friday, October 16, 2015 at 12:09:09 PM UTC-4, Alon Zakai wrote: >> >> #2: A boolean argument is nicer in some ways, I agree, but it also means >> we would need to break the existing API and force existing code using it to >> make a change. But maybe it's worth it. >> >> On Fri, Oct 16, 2015 at 7:23 AM, Robert Goulet <robert...@autodesk.com> >> wrote: >> >>> @Alon #2 is not a concern, but I don't see why this is forced, perhaps >>> just a simple boolean to tell it if we need it would be sufficient. >>> >>> @Floh As I mentioned above, a HEAD request would be much more efficient >>> than GET for this kind of operation. >>> >>> >>> On Friday, October 16, 2015 at 3:39:31 AM UTC-4, Floh wrote: >>>> >>>> As for point 3: there's isn't really a useful way in HTTP to check if a >>>> file exists, apart from firing a request and checking the returned HTTP >>>> status (the emscripten_async_wget function would call the onerror callback >>>> in that case). >>>> >>>> What I do usually is to create a table-of-content (TOC) file in an >>>> offline-build process, this contains all existing files on the web servers, >>>> and sometimes additional information like file size and MD5 hash. The TOC >>>> file is downloaded first and stored in a map/dictionary in RAM. When the >>>> actual asset files are loaded, an exists-check is done first through the >>>> TOC, thus if a file doesn't exist no server round-trip is necessary. You >>>> can also check for the existence of directories, and iterate over their >>>> contents, since all this information is in the TOC-file (and HTTP doesn't >>>> provide this functionality). >>>> >>>> Cheers, >>>> -Floh. >>>> >>>> Am Donnerstag, 15. Oktober 2015 19:41:19 UTC+2 schrieb Robert Goulet: >>>>> >>>>> Hi all, >>>>> >>>>> I have a few questions about asynchronous file system API: >>>>> >>>>> 1. Can we use emscripten_async_wget or other async methods before >>>>> we enter the emscripten main loop? >>>>> 2. The documentation says "*In addition to fetching the URL from >>>>> the network, the contents are prepared so that the data is usable in >>>>> IMG_Load and so forth...*" Is this still true in *1.34.12*? I >>>>> recall there was a change to disable content preparation by default; >>>>> does >>>>> this apply to these functions or are they still preparing content? >>>>> 3. I don't see any API to verify if a file exist before we async >>>>> wget it, would it be possible to add an API that only tell us if the >>>>> file >>>>> exist on the server? >>>>> >>>>> In our engine, the way it currently is we load resources >>>>> asynchronously, but it must be completed before we start the update/render >>>>> loop. Would that be an architecture issue? >>>>> >>>>> Thanks! >>>>> >>>> -- >>> 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. >>> >> >> -- > 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. > -- 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.
