- Where: zoom.us (see Registration below)
- When: March 9, 17:00-18:00 UTC
- Contact:
- Name: Lin Clark
- Email: lclark@fastly.com
If this is your first time attending, please fill out the registration form to receive an invite.
The meeting is open to CG members only. You can join the CG here.
The meeting will be on a zoom.us video conference.
- Opening, welcome and roll call
- Please help add your name to the meeting notes.
- Please help take notes.
- Thanks!
- Announcements
- Submit a PR to add your announcement here
- Proposals and discussions
- Proposal: Union of Worlds — slides by Mossaka
- initial feedback
- related proposal: wasi-cloud-core
- New proposal: gpio/i2c/SPI API
- WebAssembly/WASI#443
- initial feedback
- Vote: approve for Phase 1
- Proposal: Union of Worlds — slides by Mossaka
- Lin Clark
- Pat Hickey
- Dave Baker
- Brian Hardock
- Joel Dice
- Slava Kuzmich
- Emiel Van Severen
- Bailey Hayes
- Andrew Brown
- Colin Murphy
- Dave Hay
- Jeff Charles
- Zalim Bashorov
- Peter Vetere
- Chris Woods
- Ali Mohammadpur Fard
- Ben Green
- Kate Goldenring
- Piotr Sikora
- Sébastien Deleuze
- Dan Chiarlone
- Ivan Font
- Adam Mohammed
- Steve Schoettler
- Jiaxiao (Joe) Zhou
Jiaxiao (Joe) Zhou: Motivation that we want to rapidly form bigger worlds by combining smaller worlds. Will introduce new syntax. Will sketch out what that means for use statements. Simplest example: imagine we have two worlds, A and B. A is importing a, b, export c. B imports foo, bar, exports baz. We can union with the include syntax.
Include syntax should be able to specify a world path. The world path will be very similar to the use path. That means the world path will have qualifications like self, etc. Example of including external package.
More challenging example: name conflicts. Suppose we have two world, 1 and 2. Both include A and B. Besides basic include, have with syntax.
Last example, deduplication. A bit more fuzzy on this one. Want to solve transient dependency problem. Two worlds are including same. We can just rename because they are structurally the same.
Next thing is a little more subtle. Union subtyping. We define component subtyping as in the CM. What does this mean for union for worlds. This means that any component that can run in A or B is a subtype of C. This means that any imports in A or B, must be present in C. But goes reverse for exports, and exports of C must be present in A or B. But in example A, that doesn’t apply. This creates a subtyping issue we have to solve. There are two solutions. Short term, have to ask host binding to implicitly interpret exports as optional. This is just a short term solution because not explicitly expressed in wit. Longer term, need to make optional imports and exports.
Final question: can wit package store not only interfaces but also worlds?
Bailey Hayes: One thing that might help in the PR is an explainer for the difference between "use", "include", and "with"
Joel Dice: My understanding from the way wit parser works is that you can have worlds at any point in the hierarchy. I think some proposals are already doing this. Don’t know if that helps.
Jiaxiao (Joe) Zhou: Yes, it does help.
Bailey Hayes: I have a particular question about C, when you intro-ed wit. Just the dedupe that might need to happen here. Trying to wrap head around instances. In your union mu-world, you include a as a1. My-world 1 and 2 are both importing a, so that’s why you need to rename. But you now have two imports of a, which I think would be disallowed. I don’t think renaming will resolve the issue.
Jiaxiao (Joe) Zhou: : That was a mistake in the slides.
Pat Hickey: I wanted to call something out that I’m nervous will be a problem Two worlds each import two different logging. People have to agree that they’ll import under same name. If you don’t do that, you can’t compass. So it’s like you better always name wasi-logging console, or you might be stuck later.
Jiaxiao (Joe) Zhou: If wasi-logging is being imported twice in two worlds. Does it make sense to run de-dupe first so we don’t have to handle the name conflict?
Pat Hickey: Does this mean that we only dedupe when name is same and not URL.
Jiaxiao (Joe) Zhou: That’s the kind of unclear part that I mentioned. Are we going to have structural or nominal typing.
Pat Hickey: I think I’m advocating for structural typing.
Jiaxiao (Joe) Zhou: I agree with structure matching. Actually more challenging because at moment wit parser doesn’t do any structure matching.
Pat Hickey: Guy Bedford and I were talking about a very related issue last night. But that’s a sidetrack.
Emiel Van Severen: Proposal regarding embedded world. Until now, focus has mostly been on runtimes that work in very constrained envs. Also things like wasi-messaging, which will probably be used a lot since it introduces a lot of protocols. Until now, no real interface for hardware. Gpio pins, etc. I want to introduce these hardwares. Can take example of embedded Rust. SVD files created by board creators. These files can be parsed by a cli tool, and creates a lowlevel crate that allows you to write into specific registers. Devs don’t usually want that, so you often have higher level API called HALs. Two people might use different names, though. Idea for embedded HALs is to provide traits to offer compatibility. If you implement the traits, then can use across these different boards. I think WASI could be the mapping layer.
I think we should also maybe think about the high level APIs like LED. If we think about WASM, we think about completely agnostic. In this case, how do we fix? Maybe manifests like Android? LEDs could be desbribed as whether they are optional or not. This is where it’s a bit fuzzy for me. You probably have HALs that have to interface with memory. But since each has its own memory. How can I interact with the memory. If I use what’s in the module, it should be immutable. It’s a bit fuzzy for me.
Want to finish with is WebAssembly the solution. Could be a lot of work but I think the embedded world is very fragmented and this could help. Eventually people want to program in higher level languages, and I think wasm will enable this.
Bailey Hayes: This is great and I love it. I’ve also been thinking about this problem. I’ve been trying to make this work with WAMR and vxworks. Approach I’m interested in is WebIDL and a way to interop between that and wit. There are a few different APIs I think you’d be into like sensors, others. Would love to collaborate!
Emiel Van Severen: would love that.
Kyle Brown: On the subject before about different devices having different quantities of hardware, like LEDs. That seems like a good use case for wit templates. That then becomes part of the component. The component is then self-describing.
Emiel Van Severen: Haven’t looked at wit templates.
Kyle Brown: Have been several presentations.
Bailey Hayes: WebAssembly/component-model#172
Kyle Brown: Talked about sharing memory between host and guest. Might be able to handle as a transparent optinmization at the end.
Emiel Van Severen: could be an option
Chris Woods: We’ve been doing a lot on this work too. We did some perf analysis. Like Bailey, would love to collaborate. Regarding the memory sharing. Rust version you showed is something you see a lot. There’s a nuance in understanding what you’re exposing. That shifts the requirement for response time to something outside wasm. The business logic is in wasm but the underlying real time control that would be done outside the wasm world. You see that with filesystems, server for network interface. With that, you don’t need to share memory. That would map quite well with the component model. But the smaller the device, the harder it is to make the case.
Lin Clark: Ok, poll for Phase 1. Any objections? No? Congrats on new proposal! Email me to get set up.