Skip to content
This repository was archived by the owner on Aug 17, 2022. It is now read-only.

Should an API like WASI use WebIDL bindings? #28

Closed
sunfishcode opened this issue May 7, 2019 · 4 comments
Closed

Should an API like WASI use WebIDL bindings? #28

sunfishcode opened this issue May 7, 2019 · 4 comments

Comments

@sunfishcode
Copy link
Member

In WebAssembly/WASI#31, @littledan raised the following question:

When APIs for new capabilities are exposed, what is the advice for API designers, in terms of choosing between WebIDL and WASI-style APIs?

What's the advice of the people working on WebIDL bindings for people designing new APIs such as new WASI APIs?

@littledan
Copy link
Contributor

From the thread, it sounds like the idea would be for new capabilities on the web to use WebIDL and the web standards processes, so this question is more about non-web, non-JS things. The thread points to a (post-MVP, right?) challenge for WebIDL and WebIDL bindings--can this be a useful basis for non-JavaScript environments to expose APIs? What might we be missing to make this feasible? Given all the concerns raised in #25 , I wonder if a string reference type is one of those things.

@fgmccabe
Copy link
Contributor

fgmccabe commented May 13, 2019 via email

@littledan
Copy link
Contributor

@fgmccabe Could you give an example of what you would want from new nominal types? WebIDL is effectively a living standard, with features being added (and removed) all the time. It'd be interesting to hear about what kinds of capabilities would be useful for Wasm that might have been missed by looking from a JavaScript perspective.

@pchickey
Copy link
Collaborator

Closing as resolved - this proposal has been updated to match the needs of WASI much more closely than it did at the time of this discussion.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants