- Host: Google Hangouts
- Dates: Friday January 26th, 2018
- Times: 17:00–18:00 UTC (9AM–10AM Pacific Time)
- Location: same Google Hangouts link as before
- Contact:
- Name: JF Bastien
- Email: [email protected]
None required if you've attended before. Email JF Bastien to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be a Google Hangouts call.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- HTTPS everywhere
- Discussion of what this means practically for WebAssembly, and what other browser vendors' current thinking is.
- Contribution policies and repos for tools targeting WebAssembly
- Currently Binaryen and WABT require contributors to join CG and agree to its IP policy (in addition to Apache2), which is a hurdle for some contributors. Should we continue this? What are the alternatives?
- Combining Bulk Memory Operations and Conditional Segment Initialization proposals
- Should the
spectestmodule in the wasm testsuite be implementable in wasm? - Other items TBD
- Closure
None
Changed day to avoid interfering with TC39.
- Alon Zakai
- Andreas Rossberg
- Arun Etmr
- Ben Smith
- Ben Titzer
- Brad Nelson
- Dan Gohman
- Derek Schuff
- Eric Holk
- JF Bastien
- Jacob Gravelle
- Luke Wagner
- Malcolm White
- Marat Dukham
- Marco Trivellato
- Paolo Severini
- Peter Jensen
- Sean Westfall
- Sven Sauleau
- Thomas Nattestad
- William Maddox
- Wouter van Oortmerssen
- Yury Dekendik
Derek seconds.
JF volunteers.
Brad says progress on the spec. Now goes through katex (all math is rendered offline!) and passes W3C validator. Luke is enthused. It’s a single page for now, some people like it, some less so.
https://flagxor.github.io/spec-drafts/spec/bikeshed_katex/
No other progress to report.
- JF: TC39 sometimes feel left out, and want to make sure things such as weak refs don’t just sneak into the web platform.
- JF: Discussion of SAB being pulled. No real action for now.
- Brad: the group is very functional now! The new chair, and their little web app to control speaking are great.
- Peter: anecdotally biggest TC39 I’ve been to.
AI: JF to talk to Brian about using that tool.
Discussion of what this means practically for WebAssembly, and what other browser vendors' current thinking is.
- Luke: rationale is everything, even small features, would be HTTPS to help push adoption. There’s a reasonable practical limit, we can’t gate every tiny thing, but new opcodes could cause validation to fail. Multivalues might not need to be gated because it only removes a restriction. Anything significant would force secure context. What would be great is if we can put this in the JS spec so that implementors can sync if they so wish, and users can know which APIs fit this.
- JF: we’re not ready to express an opinion on this. I’d like non-browser people’s inputs.
- Brad: would say exception handling be under this?
- Luke: yes.
- Brad: feature detection?
- Luke: yes this would just work with feature detection.
- Brad: you don’t remove any API surface?
- Luke: no.
- Brad: fun tidbit, ad networks now use WebAssembly to detect real browsers versus low-capability bots.
- Luke: if our tools just hide constructors (e.g. the “try” opcode constructor) from the JS API spec, then it’s very simple to specify.
- Brad: I’ve spoken to folks at Google and we definitely haven’t reached consensus yet. Whatever we do, we’ll reach an independent consensus. Some folks are proponents of a similar direction, but we try to balance with what’s most useful for the web overall. We definitely want HTTPS everywhere. One caveat is if WebAssembly finds itself on common frameworks, then they’d have to use older toolchains because they can’t use e.g. exceptions. One of the things we’re trying to figure out is how localhost is treated.
- Ben Smith: how would we add this to the spec? What’s the status of addressing these types of limitations such as max sizes?
- JF: open action item to do so.
- JF: it would be nice if WebAssembly weren’t the first spec to ship this kind of feature behind secure context only. If other web specs did it first it would be easier for us to figure things out.
- Brad: this might propagate the life of asm.js.
AI: group, always discuss secure context for each new feature.
Derek presenting
- Derek: Currently Binaryen and WABT require contributors to join CG and agree to its IP policy (in addition to Apache2), which is a hurdle for some contributors. Should we continue this? What are the alternatives?
- Derek: Other tools such as LLVM are in their own repo.
- Derek: The IP policy is a hurdle to contributing versus Apache2, because lawyers don’t know about it, it’s just different, and they have to do research versus just agreeing to Apache2. This adds contributor friction.
- Derek: Original intent was that any significant contribution to the spec needs to be protected by W3C IP agreement. Tools sometimes contribute new ideas to the spec. On the other hand, one could argue browser implementations are the same, and are in their own repo without this protection. We just make sure that bringing things to the spec is done by CG members. Also, as new tools get developed they probably won’t be under our repos and our W3C agreement.
- Derek: At the same time, our charter makes it clear that tools aren’t part of the CG / WG deliverables. Note that we didn’t have a charter when we initially decided to put the tools under the IP agreement.
- JF: if we make a decision I’d like to make it slowly so that it doesn't seem like we’ve snuck this in. I’d like to bring it up at the WG meeting (with W3C reps resent) and maybe in-person meeting, before making any decision binding.
- JF: I want to make sure we don’t overly privilege any tool by putting them under the WebAssembly organization. I’d be wary of accepting anything too, because then we’d have problems similar to npm’s where there are complex security issues to how things are managed. Maybe we can just grandfather some projects in, and not accept new ones, or move some out to individual orgs.
- Derek: practically speaking, we also grant privilege by having our engineers working on these tools. There’s some reliability and up-to-date-ness.
AI: Brad to put this on the WG agenda. JF to bring back results to next CG meeting.
Ben Smith presenting
We talked about this at the last meeting (splitting 3 proposals out of the threads proposal). Rossberg pointed out that these two are pretty similar and could be combined, instead of having two self-standing ones.
POLL: unanimous consent to do this merge.
Should the spectest module in the wasm testsuite be implementable in wasm?
Dan Gohman presenting
Some of the tests import a module called spectest and import a function called print which is overloaded by the embedder. Each import re-imports it with a different signature, but that’s weird because WebAssembly itself doesn’t have overloading. That way you could implement the spectest module in WebAssembly. Same with kinds: a global and function could have the same name.
- Andreas: we could remove it from core tests, but we should still make sure that it validates.
- Luke: I like the principle of being able to implement standard library in WebAssembly.
- Andreas: I would propose removing the print function from the spec tests. We should use assertions instead. It’s no longer relevant. We’ll still test imports, but it doesn’t have to be print.
POLL: unanimous consent to remove polymorphic imports.
AI: Dan to update spec tests to not be polymorphic.
Rename to mem.grow, and mem.size. This would be a change to the text format, but compatible with binary otherwise. Should it be mem or memory? We’ve been inconsistent in naming. Would the section now be “mem” as well? JS API is a different topic.
AI: move forward, and discuss next meeting.
Out of time