Re: Emscripten Asynchronous File System API questions

2015-10-16 Thread Robert Goulet
The problem I was trying to solve was to write on disk the content of a binary buffer that was in memory when running the JS generated from emscripten. I found a clever way to do that: I encode the content of the binary buffer to base64, then I create

Re: Emscripten Asynchronous File System API questions

2015-10-16 Thread Alon Zakai
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 i

Re: Emscripten Asynchronous File System API questions

2015-10-16 Thread Robert Goulet
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 brow

Re: Emscripten Asynchronous File System API questions

2015-10-16 Thread Alon Zakai
#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 wrote: > @Alon #2 is not a concern, but I don't see why this

Re: Emscripten Asynchronous File System API questions

2015-10-16 Thread Robert Goulet
@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

Re: Emscripten Asynchronous File System API questions

2015-10-16 Thread Floh
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

Re: Emscripten Asynchronous File System API questions

2015-10-15 Thread Alon Zakai
2. Not currently. Is this a concern - are you downloading a large number of images or audios? If necessary, we could add an api like emscripten_async_wget_without_preload_plugins() 3. Makes sense, although it's also pretty simple to do with an EM_ASM block with an XHR. But I can see that a C API m

Re: Emscripten Asynchronous File System API questions

2015-10-15 Thread Robert Goulet
1. We are not in the main loop yet at that moment, so I guess I have to keep blocking the main thread with a semaphore waiting for all resource threads to finish, just like we do on other platforms. 2. Ok is there a way to disable it? 3. What about a HEAD request? That would b

Re: Emscripten Asynchronous File System API questions

2015-10-15 Thread Alon Zakai
1. Yes, the main loop and async_wget etc. APIs are not related. Although, you might want to pause the main loop while waiting, but whether that makes sense for the app depends on the app. 2. Yes, still true. 3. I'm not sure how to check if a file exists remotely aside from trying to load it and s