georgestagg
commented
1 year ago There are a couple of things we'll need to think about before making a decision on this,
- It looks like this is only available when
-sFS_DEBUGis set. It would be good to know the other consequences of setting this flag. Enabling a debugging flag for production does not feel very elegant. - If enabled, the FS events and callbacks would be fired in the worker thread. We would need to work out a scheme to pass on information that an event was fired to the main thread, probably using new message types over the established communication channel.
- I can't be sure that the FS events would actually fire. For technical reasons, we block in the worker thread deep inside the R Wasm process and don't yield to the normal JS event loop. As such, the FS callbacks might never fire. It depends how it's set up in Emscripten - I'd have to check the source or just test it to be sure.
I am also planning to work on a "seamless" sync of the web_user tree to local storage that happens in the background.
Watch out for browser localStorage quota if you are saving very large data files.
I think a good way to do this is on the worker thread with a custom Emscripten FS layer that is able to persist data to browser storage, mounted somewhere on the virtual filesystem like /data. Ideally, I'd like to use something like that with OPFS to automatically persist user data without having to transfer the data files through the main thread. Though, again, blocking in Wasm can make this difficult.
The Emscripten team are currently working on a new WasmFS FS layer that is able to handle multiple backends (including OPFS). Once that is ready, we may simply be able to mount the WasmFS layer at /data or /home/web_user to enable a persistent user file store.
hrbrmstr
ref: https://emscripten.org/docs/api_reference/Filesystem-API.html#FS.trackingDelegate%5Bcallback%20name%5D
This would let apps, like my janky IDE, watch for filesystem changes in a far more lightweight way. Helpful for knowing when to update the FS display without having to run a regular async job or (in my current case) re-update it after every input call.
I am also planning to work on a "seamless" sync of the
web_usertree to local storage that happens in the background, and the evented approach would be far more repsonsive.I can try to take a poke at this if it sounds like an ok idea to the core maintainers.