Mapping .NET File System API's to Indexed DB (IDBFS)

[groogiam]

Is your feature request related to a problem? Please describe.

This issue dotnet/aspnetcore#15492 from a couple years ago discussed the removal of the enscripten file system api in favor of another mechanism in mono. In the .NET 5 blazor implementation it looks like IDBFS is libraries are no longer linked from enscripten. I was wondering if the newer mechanism has been implemented? If so is there documentation for this mechanism somewhere? Thanks.

Describe the solution you'd like

Looking for a way to map map file system api's to indexed db locations in blazor wasm.

Additional context

Add any other context or screenshots about the feature request here.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is your feature request related to a problem? Please describe.

This issue dotnet/aspnetcore#15492 from a couple years ago discussed the removal of the enscripten file system api in favor of another mechanism in mono. In the .NET 5 blazor implementation it looks like IDBFS is libraries are no longer linked from enscripten. I was wondering if the newer mechanism has been implemented? If so is there documentation for this mechanism somewhere? Thanks.

Describe the solution you'd like

Looking for a way to map map file system api's to indexed db locations in blazor wasm.

Additional context

Add any other context or screenshots about the feature request here.

Author:	groogiam
Assignees:	-
Labels:	arch-wasm, area-System.IO, untriaged
Milestone:	-

[danmoseley]

@marek-safar this isn't something we have expertise in. Is there someone on your team with context here?

[kjpou1]

Right now the System.IO.FileSystem is mapped which offers posix type of file interface.

Including File System Support we build the default in by passing -s FORCE_FILESYSTEM=1.

Each file system support adds size to the dotnet wasm files so we are only supporting thethe MEMFS filesystem by default. Plans to implement or map the others I do not think are planned right now nor the immediate future.

[kjpou1]

https://github.com/wtulloch/Blazor.IndexedDB

Maybe this will help ^

[groogiam]

Is there any metrics for how much space the -lidbfs.js https://emscripten.org/docs/api_reference/Filesystem-API.html#filesystem-api-idbfs flag would increase the size? It seems like it would be really useful have the ability to write to some sort of persistent file system via the standard System.IO api's. In terms of PWA's that support an offline persistence mechanism this seems like it would be extremely useful.

[kjpou1]

Right now we are in the process of trimming as much as we can to make the system footprint as small as possible. This might be a future enhancement but is not planned for now. There are Blazor specific solutions that provide this for now.

[groogiam]

Fair enough. I have one more question about the mono wasm implementation included in Blazor. Does it support dynamic linking of wasm modules? E.g. ENABLE_WASM_DYNAMIC_RUNTIME=1 on the mono build. In regards to the previous question I was hoping to maybe be able to add a wasm module for SQLite which could then be called via the EF Core driver. The UNO project had this ability but I'm not sure if the wasm build blazor is using supports this use case. Thanks.

[kjpou1]

Here are the switches used to build the implementation: https://github.com/dotnet/runtime/blob/master/src/mono/wasm/Makefile#L66-L75

We do not support dynamic linking at this time nor do we have a time frame at this time to provide the support.