-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offline capability #25
Comments
So yeah. Data URL doesn't help there, aside maybe from being able to replace the blob urls with the data urls, which avoids having to manage the blob resource. Upon further inspection, it seems that these requests come in 2 pairs of blob url + request. One pair is the worker module polyfill. If I configure out that code, then I avoid one non-load-bearing and one load-bearing request. Which could be a PR btw. I was unable to remove the initial request, even with The other part is the original wasm_bindgen shim. That load is triggered from the I wonder why you don't url-encode the original shim and provide that url with search and replace? AFAICT, if you do that, and the same with the polyfill (or make it easy to configure out, as I was showing) then it should work out? Currently you just encode the worker script itself, which, when compared to the wasm bindgen shim, should typically be much smaller. |
Another interesting thing to me, is that the wasm script only gets downloaded a single time. This should happen in the generated shim file. I would like to investigate what that script does to avoid another download for the worker. I can't even see a blob url request or similar. |
My understanding is that the initialization code creates a global wasm variable, which seems to also be accessible from the worker(?!) which you then use in the At least I cant find any root-level statements in my generated shim aside from the stuff at the very beginning, which only declares the wasm variable, but doesn't assign it. It only gets assigned in a function, that AFAICT only gets invoked in the main thread in the beginning. So the wasm global is available in workers by default? I'd assume its a copy, if present, not shared? |
oops. I overlooked the init call in the worker script. Well, that explains parts. |
I've further investigated this. Solving this would be difficult, and the hack would remain. But it should be possible with a similar approach to whats done for the worker script, with a manual fetch request for the bindgen js file. But it won't be easy. I don't have the energy to do this. I've since reevaluated using serviceworkers for offline-capability and got things working to my satisfaction. Feel free to close this, or keep it open if you care for it. |
Hey! I've been using this library for a bit now, and its really amazing for what it can do!
However, currently, when I open my project and then spawn a thread, each time there are still requests going out, so far that it doesn't work if my browser is offline (I also don't have a caching serviceworker, which might be able to help).
Precisely there's 4 requests going out, 2 of which transfer 0 bytes and still seem to work offline, 2 others where at least the first fails when offline.
To be entirely honest, I don't really understand the entire business with the js scripts thats described in the readme. However, it is my understanding that this is required because webworkers require to be started from a URL. BTW, the urls in that readme are dead, the paths they reference have changed. Its easy enough to find the correct files, but it might be worth a quick fix.
I did a bit of looking around, and this stack overflow question and answer imply that its possible to use a data-url for the serviceworker.
This should mean that its possible to do this request, from my understanding, without that complicated hack to get a url, and its possible entirely offline.
I'm uncertain whether this will actually enable everything to work offline. I'm under the impression that one of the 2 network bearing requests in my case is for the generated js-wrappers from wasm-bindgen.
But I hope that you may have more insight into that, and I thought perhaps you would be interested in using a data-url to avoid the current hack, even if this doesn't add any features.
The text was updated successfully, but these errors were encountered: