- Where: zoom.us
- When: March 28th, 4pm-5pm UTC (March 28th, 9am-10am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Proposals and discussions
- Phases doc clarifications (#1232)
- Closure
None
None
- Deepti Gandluri
- Thomas Lively
- Ilya Rezvov
- Ryan Hunt
- Alex Crichton
- Conrad Watt
- Paolo Severini
- Ben Green
- Manos Koukoutos
- Yury Delendik
- Derek Schuff
- Brendan Dahl
- Daniel Lehmann
- Luke Wagner
- Matthias Liedke
- David Piepgrass
- Jakob Kummerow
- Andreas Rossberg
- Chris Fallin
- Ashley Nelson
- Sean Jensen-Grey
Phases doc clarifications (#1232)
AR: Clarifying PR, nothing in there should be controversial, it is changing the process document so we thought it might be best to bring it up in a meeting.
AR presenting PR.
AR: Historically, the how-to is in the proposal repo and the phases doc s in the meeting repo, it’s a bit weird. Maybe we should move the phases doc to the proposal repo. ANyway, something to solve for the future.
AR: Previously we had that the spec text ust be in “reasonably complete” state. We’ve never done that, we’ve just had informal prose that was precise enough, but not “real” spec text. But usually you don’t do that until after you have formal language and turn it into prose. So we’re trying to reflect that reality by avoiding the term “spec text”. Just a doc that has to be “precise enough” that someone could implement it. So it should be precise and complete but needn’t be spec text.
AR: Another clarification for the test suite is to not have to pass the reference interpreter (since you don’t have to update the reference interpreter yet), but there should be some implementation that it passes. There has to be something that passes the tests, the purpose is not correctness, but that the tests pass some implementation and make sense.
AR: Here it’s really just mostly wording that I tried to clarify. At this stage you need the formalization and also the English prose. Reflects the reality that they are usually written together. You can do it earlier but has to be done by now. Also, at this stage we want to resolve all open questions. Usually there are some minor open questions, even though the overview is precise and complete there will always be a few things open, and we want to close those. So here is where proposals will sit for a long time until we get everything discussed and resolved.
AR: It's also clarifying that it's happening in the forked repository. There was another vague statement, we had some discussion about what it means, that’s been split up and clarified.
AR: also for the last phase when it’s handed over to the WG, that means when we vote into stage 4 we’ve reached consensus in the community group. And at this point in phase 4 we just do tweaks or whatever. The WG may discuss the feature but usually there’s nothing to discuss since they were already involved. But the WG needs to discuss when to merge things into the spec. With Tail calls we were ready to merge it, but Apple pulled their implementation back out, so we decided to wait to merge since we didn’t meet the requirements anymore.
AR: At that stage there can also be editorial changes to the spec. The last part is standardized. The precise W3C process evaded me, but this would be useful to flesh out. How to release candidates etc. is not very clear, hopefully we can add more detail to this later.
AR: one thing I didn’t change although I think we should really change it, is the requirement regarding the 2 implementations. It says web VMs, but we should discuss whether to change ti to say one of the implementations doesn’t need to be web VMs. We have production non-web VMs, and there is a decreasing number of web VMs, so it makes it harder. But that’s not in this change, everything here should be non-controversial.
DG: thanks for working on and clarifying this!
Unanimous consent poll: no objections, changes are approved.
AR: is there any appetite for discussing the web engine requirement?
CW: we should probably give some warning for that discussion, there might be people who want to be in on it, who might show up for that but not here.
AR: we should be discussing this soon.
CW: my hot take is that we should be scared of relaxing the requirement because V8 has been running far enough ahead of the other web engines that we risk standardizing things that they don’t intend to implement.
AR: Part of the motivation is to put more pressure on other engines if they fall behind. It’s not enough for V8 to run ahead, there still has to be a second production engine. Right now, outside of the web space, wasmtime would be the one that qualifies. And wasmtime isn’t running ahead, so this wouldn’t change the game. The other two web engines besides V8 are JSC Apple and Spidermonkey Firefox and both of them have not been particularly quick and have often been a blocker for adopting features.
RH: my question here is, in what cases have we been blockers? I see tail calls but are there other examples?
AR: Tail calls are a particular one, but was there something else?
CW: I'm a little worried about stringref. I wonder if Mozilla has been looking at that.
RH: We’ve been looking into it, but we don’t have an implementation at this time
AR: there are quite a few proposals that have been at phase 3 for a long time that people are eager to start using.
RH: I believe memory64 is mostly blocked on toolchains, we have an implementation of that. Multi-memory we have a prototype implementation that’s been going slowly. It hasn’t been a priority for us. We’re also working on GC but there’s been plenty of spec work there too.
AR: it’s also about changing the perception of what wasm is. It’s no longer just a web thing and our process should reflect that.
CW: I would make a distinction between the browsers being in sync and the non-web engines implementing features
AR: no engine is required to implement the latest version of the standard as fast as they can. Even when we had 4, some were lagging behind and that’s fine, it’s their choice. For the standard to be adopted , it shouldn't be a requirement that everyone implements it. The standard should drive adoption rather than follow behind. So this requirement for 2 engines to have implemented is not so that everyone is up to date but to ensure that whatever the proposal is, we are sufficiently certain that it’s reasonable and can be implemented across a wide variety of engines.
CW: I could be convinced it would be okay to have one web VM and one non-web VM as long as there was a signal a web VM would implement it. I think a signal of implementation from our big stakeholders is missing.
AR: that’s the other thing, all these are just the base requirements, you can’t proceed unless they are met. But it’s not sufficient, there still has to be a vote in the CG. if there’s real concern by other vendors, it will come up there. So this is about not having unreasonably high minimum requirements.
DG: I like the idea of using the signal process, I know Mozilla and Safari have their own GH repositories which track signals and Chrome release process uses that for Origin trials to see when other engines will implement proposals. Maybe we can’t discuss this in this meeting, but every time we discuss this, what does a production engine look like in the non-wasm space. But there are other engines that implement features that are to some degree production engines. How do we firm up the requirements around what a production engine looks like if it is not a web VM. Some questions about how to navigate that. The second thing is we want to have a case of a minimum tool engine requirement here because for multi-memories it has been really interesting, there are a lot of use cases, but there hasn’t been one big reason to implement it. In cases like that, the two engine requirement makes sense. I want to make sure that people are going to use it if it’s going to be part of the requirement.
PP: There could be situations where an engine doesn’t find the feature useful/compelling. Similar to what DG said.
TL: I don’t really want to be in the business of deciding which engine is production grade, and then we don’t have unanimous consent on when an engine count
PP: Case in point, when we met before the in-person CG, there were so many presentations on e.g. WAMR, e.g. Seimens said they are using it in “production” but that means different things, it’s not as clear as in browsers.
AR: Procedure for marking engines as production so this CG could take a vote on recognizing a given engine as production engine and from that point on we can accept it as that so we don’t have to discuss it every time. We can discuss what the requirements will be or leave it up to the vote. Decouples from the process document. I think that would solve tha problem. It’s an additional process stage, but should work fine. Let’s not indefinitely give web engines this privilege they have now. I think it woud be harmful to wasm as a whole/ecosystem. More of a philosophical/marketing question. In practice, probably won’t change much.
PP: wouldn’t part of the problem be that sometimes web engines and non-web engines may have completely different interest. We may have features taht are web only or standalone-only. There’s WASI but it’s a set of APIs rather than a core feature.
DG: Interested in hearing from Luke about the non-web perspective.
LW: I was just thinking, what are some of the useful properties of web VMs that make them good, that we could apply to other VMs. they care a lot about security and longevity of the implementation. E.g. can we make this secure, and can we support this for a very long time. We can also recognize when developers of other engines are taking those same considerations.
AR: Makes sense, maybe we should come up with a list of requirements that we kind of state for a production engine to be recognized and discuss that.
SJG : Reference engine implementation? Engine conformance tests? If it passes the conformance tests, then it qualifies.
CW: maybe this is too harsh of an opinion, but i’m not sure we want to work this out eagerly, maybe we should wait until there’s a proposal where this matters, and then we can figure how how we want to deal with it.
AR: I would argue the exact opposite, we want to do that before it becomes controversial.
CW: Hence everyone agrees for example, if we get in a world where wasi wants to go through the process to become a separate spec document we are endorsing. Clearly we don’t want two web VMs to implement it and that’s the kind of stage it would make sense to have that discussion instead of tryign to predict which features would need an elongation of the proposal procedure.
AR: WASI is a different story anyway, since it’s not like core wasm. For standards like that we can certainly have different procedures. But i’m also concerned about core wasm, because the more users we have outside, the less represented they feel if all our requirements are based around web engines. Some of these use cases have quite otehr pressing concerns. Some care much more about the memory extensions but much less about SIMD, but traditionally the priorities in the web world are the opposite. But it would be good to get their views better represented.
DG: I couldn’t track down the notes but long ago in a meeting I discussed this and we talked about loosening the languages around our requirements document for a production engine that has unanimous consent for specific proposals. I don’t remember the exact wording but could we consider it async. What language makes sense to loosen ther restriction and argue that a different production VM is implementing it in addition to a web VM. I agree to CW, we want to make sure something is actually blocked to actually move forward, we’re not meeting the two VM requirement. Temporary middleground we can flesh out async, as long as there is unanimous consent about a production engine qualifying for a specific feature. How do people feel about that?
AR: how is that any different from just saying that a non-production engine might qualify? To be precise i have in mind to say that we require 2 production engines, one of which must be a web engine. I think thats the same as what youre’ saying, and we can discuss in each proposal whether the engine in question qualifies for that proposal.
DG: The thing I was suggesting is we have one web VM implement it and a second engine implement it that is not a web engine. The thing I’m suggesting is not saying two web VMs have to implement it, leave wiggle room to bring it to the CG. Unanimous consent to consider a different engine. Then we can work on what Luke said, quantify what the requirements are and see how it applies to non-web VMs.
PP: unanimous consent is the difference I think. That’s a strong requirement. If we just say “a production VM” that's open to debate, but if we say “ a production VM and we have to discuss it in a meeting” that should be less controversial
AR: Difference is, we’d still have a vote in both cases, there cannot be any against vote. Is that the only difference?
DG: yeah, that we have a unanimous vote to consider a different implementation
AR: That would at least be some progress.
CW: Andreas, do you have a specific proposal in mind that needs this to go through? Are you thinking of multiple memories for example?
AR: My point is this wouldn’t be tied to a specific proposal but reflect the reality of the wasm world as it is today, more for representation reasons than concrete decisions. And I think it’s good to consider that before something comes to concrete. Because then there are all these biases that will convolute that people will argue at that point. So if we can resolve this independent of any concrete thing, I think that is much more tenable.
PP: we should discuss what exactly we mean by “production” engine rather than just relaxing the language. If we just reduce the requirement, it’s less strong, even if we require one, but from a completely different world, it makes even weather. Maybe also this is related to profiles as a mechanism, if you’re building something that will never be implemented on the web, then you don’t need any web engines.
AR: Fair but I think that is the wasi case which is a different discussion if there are features where the web is applicable. N/A to the web. I also care about features that are core wasm that everybody will potentially want, or many will and what do we do about those. I think we’ve discussed this enough. DG’s point makes sense to me, we can make progress from there.
SJG: i think there are 2 issues: does the group agree that they want input from non-web engines on passing what needs to be voted on, and second the mechanism to achieve that goal. E.g. you could count the number of web and non-web voters that vote for it, you could track whether you have support from implementers of non-web engines, and are we hearing from them. So, is that a direction that
DS: We’ve always wanted to have that input, it hasn’t been easy. In the browser space, people are accustomed to dealing with web standards, whereas its a much less familiar thing for people with other backgrounds. This really goes back to what Luke said, it would be better to discuss ahead of time for what properties of mature engines that we want to see in non-web engines
SJG: The risk of having some nascent web engine and dictate how the standards move forward is low. The number of mature wasm engines we could just list them out and if someone wants to be on the list, we say how come. The # of non-web engines that exist is finite. We can make a non-exclusionary list.
DS: Those are the different options, do we have an explicit list of features we want to have? We’ve definitely heard of folks embedding WAMR, Wasmtime, which could count as production. Do we want to have a blessed list? Or do we make the distinction on which proposals make sense for which environments?
SJG: I’d include wasm3 since it includes older environments. It’s nice to get feedback from those engine authors about what would be harder to implement. It would be nice to get their feedback on these things.
CW: Yes, it would be nice to get feedback, but I would argue that that raises the bar for existing proposals. But the issue seems orthogonal to relax the requirements for a particular proposal
RH: I think that's where I’m leaning. Iconservatively i would want to relax this when there’s a real issue. There’s a lot of spec work, toolchains etc that seems to be the bottleneck rather than the VM requirement. I haven’t seen that be a real problem yet. I’m open to be convinced about this though.
SJG: What does conservative mean in this process?
RH: Conservative means changing the rules when its a problem and not eagerly
PP: The point about gimmicks, the non-browser implementations we should just collect feedback. On the different directions groups can take, we don’t know how this is going to affect. Embedded engine says something needs to be in a standard, is that okay that someone in the browser world may do extra work? Really an interesting and difficult question. I know that one other solution is CG to have some of the web apis to add them to the JS requirements, like nodejs. So they are looking at which parts can be relaxed. So maybe web and non-web can be viewed as what subset/superset you can have. Which features need to be slightly tweaked.
LW: one thing i’d also point out to give some mor color here: in addition to the non-browser engines that have been mentioned. Other ones that have been used in production include wasmedge and wazero, thy
DS: Another criteria that occurred to me is that do developers give feedback in some way or do they participate more actively? We would want more active participants.
AR: That sounds good too. I want to push back a bit on what Ryan said that we should only change things if there’s a problem. This is a little like legislation. But laws shouldn't change only when people are harmed. They should be changed when they are bad or need to be improved, even before that happens.
RH: I think one important thing is to see if there are victims of a law, but just semantics.
AR: i think I disagree with that?
DS: We get regular input from wasmtime developers, and folks that are working on WAMR, the other ones less so.
PP: This mneeting is inaccessible to WAMR folks, it’s middle of the night for them
DS: You are a regular participant, do you understand their positions enough to have a sense for what they think or represent their opinions do you think? Not trying to put you on the hook but wanted a sense.
PP: I have some idea but I Would need to talk to them more to be useful.
DS: We should continue this in a future meeting, or follow up on github. But this is an important discussion