What API functionality would you like?

[philpax]

Heya! As your resident API designer, I find myself needing to figure out what to prioritise for future development. This is your avenue to lodge requests that I can then start to sketch out and/or make issues for and/or build. Just let me know what you need!

[philpax]

A way to read/write files local to your project

At present, all file I/O is disabled for WASM/WASI, aside from stdout/stderr. This is intentional as it's very hard to make this secure after the fact. That being said, being able to read and write state is very useful.

The resulting API should have the ability to:

• read or write arbitrary text or binary files, up to a limit
• all access is restricted to a specific folder in your project and/or a directory relative to the runtime
• should work in all deployment environments, including during development and deployment to a user on both desktop (all operating systems) and web
• should not work on the clientside
• should not have a way to escape the sandbox it's in - whether through oddly constructed paths or through access to system files
• should enforce that filenames are valid for all deployment targets (no characters that are invalid to Windows)

[DCNick3]

should not work on the clientside

I think it might be useful to save some state even for the clients. Some user-specific settings, for example

[philpax]

A function to read the binary contents of an asset (suggested by @owenpalmer)

If an asset is available to the server, it seems reasonable enough to allow both the client and server to read the contents of that asset within their WASM.

This would look something like asset::read(asset_url: &str) -> Result<Vec<u8>, AssetReadError>. The asset_url function would also be likely moved to asset::url.

[philpax]

See #506

[owenpalmer]

@philpax What are your thoughts on having an option to control components before they change, and maybe preventing the change under certain conditions? For example, in addition to track_change, you could have track_before_change() or track_pre_change().

[philpax]

Hm, that would be a little difficult to do because the change to the ECS would have to be stalled until all the trackers get to it. What would be your use case?

[philpax]

I'm going to close this in favour of separate issues - see #531 and #506.