-
Notifications
You must be signed in to change notification settings - Fork 55
Should an API like WASI use WebIDL bindings? #28
Comments
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. |
There is some exquisite pain in my response to this.
webIDL itself seems very strongly tied to web APIs. I.e, it is not really a
'general purpose' IDL. For example, it does not support new nominal types.
Furthermore, wasm's ontology does not even meet the level of webIDL.
Probably, the best long term approach is to use webIDL for new APIs, but
then be prepared either to compromise the design or fight for changes to
webIDL itself.
Note that webIDL is itself a simplification of Corba IDL.
…On Sat, May 11, 2019 at 5:12 PM Daniel Ehrenberg ***@***.***> wrote:
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
<#25> , I wonder if
a string reference type is one of those things.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#28 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAQAXUG7JMAKRKNSYSUAHSTPU5OFVANCNFSM4HLEMNFA>
.
--
Francis McCabe
SWE
|
@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. |
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. |
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?
The text was updated successfully, but these errors were encountered: