WIT standardization

[ricochet]

During the WASI subgroup meeting today, we discussed the need for standardizing the WIT IDL. (Notes)

The question raised is if WIT should be standardized as a part of WASI, the component model, or its own thing?
Is WIT separate from the component model? In many ways it has reacted to and grown with the component model (f32->float32, function->func, will add support for features of the component model like streams, async, etc).

Raising this as an issue to continue the discussion.

[joshtriplett]

I would propose that WIT should be the standard IDL of components. Either it should be standardized with components, or it should be adopted at some lower level if there is ever a desire to have a "less raw" native interface for WebAssembly itself.

I don't think we want competing IDLs; I think we want one standard IDL with complete support for everything we want to support.

[fgmccabe]

When offering an IDL, one must consider who would use it. I am especially concerned about using an IDL to define interfaces, for example by an Enterprise Architect.
EAs use IDLs to define interfaces to help define the overall architecture of their system (it is not at all uncommon for a large system to have 10K+ interfaces to manage).
Making WIT a separate element, suggests that the EA might use it to define all their interfaces; this is probably not reasonable. In that case, a WIT file would typically be a derived product from some other IDL. This has the positive benefit of allowing WIT to focus on the Components use case.

[joshtriplett]

I would not be at all surprised if people use other higher-level mechanisms to generate WIT; among other things, they may generate it from their preferred development language, or from a no-code tool, or any number of other solutions. I don't think that'd be an obstacle to standardizing WIT as the underlying IDL.

[lukewagner]

Sorry for waffling on this question a few times :) In addition to the reason Josh gave above, I like the argument that wit is very intentionally keeping in lock-step with the component model and so it makes sense to standardize them together so that a PR to the component model can simultaneously update the AST, binary format, text format and IDL of components, allowing us to see and discuss the net effect.

[theduke]

Does that mean all standardization discussions should move to the component-model repo?

[lukewagner]

Just those discussions concerning the syntax of wit. Already, the semantic types (of wit) were primarily discussed in the context of interface-typescomponent-model, so this would mean including the concrete (non-sexpr) syntax as well.

[theduke]

Just those discussions concerning the syntax of wit.

Alright, thanks!
I have several suggestions on the syntax side.
I'll open issues for those.

[ricochet]

Thank you for the discussion everyone. We appear to have a consensus for the following takeaways:

• Wit should be standardized with the component model
• Wit should be the standard IDL of components
• PRs to the component model shall simultaneously update the AST, binary format, text format and IDL
• Expect higher-level mechanisms to generate WIT. Software stacks will continue to define architectures through other means (e.g. openapi, CBOR, protobuf, models with code, etc). One feature of wit is that it is generatable from inputs. The focus for wit will be on Components.

[lukewagner]

Great summary @ricochet; that sounds good to me too! To be extra tidy about this decision, submitted a poll for the next next WASI meeting.

[ricochet]

One more addition: wit profiles should be included as a part of wit and standardized with the component model.

[sunfishcode]

For anyone following along here, WebAssembly/component-model#70 is a PR adding WIT to the component model.