- Dates: Monday-Tuesday November 6-7, 2017
- Times:
- Monday - 8:00am to 6:00pm
- Tuesday - 8:00am to 6:00pm
- Location:
- Hyatt Regency San Francisco Airport; 1333 Bayshore Highway Burlingame, CA 94010
- Sandpebble B, Lobby Level
- Wifi: TBD
- Contact:
- Name: Brad Nelson
- Phone: +1 650-214-2933
- Email: bradnelson@google.com
Hosted by W3C TPAC. See the site for details.
Opens June 2017, see TPAC page for details.
See TPAC page.
Swing by and talk about WebAssembly! WebAssembly folks and others can discuss topics of interest.
Official meeting of the WebAssembly Working Group.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Host facilities, local logistics
- Find volunteers for note taking
- Adoption of the agenda
- Approval of the minutes from last meeting
- TPAC Welcome
- Welcome to TPAC (Brad Nelson).
- Introduction of our W3C Team member Eric Prud'hommeaux.
- Proposals and discussions
- Discussion on increased coordination with other W3C Groups.
- We'll talk about where we should be collaborating more with other groups, how we conduct outreach, and plan.
- Discussion on the status of the specification.
- Discussion on increased coordination with other W3C Groups.
- Closure
Presenter: Brad Nelson
Brad will give a quick rundown of all current in-progress WebAssembly proposals. We'll talk about where each is at in terms of our phases and the obstacles each proposal faces. Slides.
The Web Performance WG is discussing the Lifecycle API.
As modulating things like xCoin mining has bearing on WebAssembly, our group should go to the WebPerf Room (Sandpebble C, Lobby Level).
Free-form mingling in the WebAssembly Room
Presenter: Ben Titzer
Ben will give a high level overview of WebAssembly.
Presenter: Derek Schuff
Emscripten is WebAssembly's toolchain. Derek will give an introduction on how to use it, tips and tricks, and where it's going.
Discussion on Web Platform Tests.
Come see Demos of WebAssembly:
- Google Earth (preview) - Live demo only
- WebDSP
- Construct3
- Epic Zen Garden
- WebSight
- NASA Access Mars
WebAssembly folks and others can discuss topics of interest.
WebAssembly and WebAudio WG folks to discuss future APIs, performance interactions, and avoiding garbage introduced by the API.
Presenter + Moderator: Heejin Ahn
- Presentation on Control-flow in WebAssembly + current state of exceptions proposal. Slides.
- Discussion
Free-form mingling in the WebAssembly Room
Presenter + Moderator: Corentin Wallez
- Presentation on WebGPU
- Discussion of WebGPU Topics, especially Wasm related ones:
- Fast bindings for Web platform APIs (call overhead and GC-less render loop)
- How to make the API interoperable between JS and WASM
- Is the WASM host mapping buffers in the WASM module memory space a thing? (glMapBuffer equivalent)
- Multithreading story for APIs
- API extensibility in WASM (can't just add a dictionary entry like JS) *Any questions you might have!
Moderator: Brad Nelson
Discussion on what bearing coin mining and other CPU abuse has on WebAssembly. Follow up discussion of Lifecycle API.
Presenter: Brad Nelson
WebAssembly currently in practice relies on a substantial amount of support from JavaScript + Web APIs to be useful on the Web. Interoperability with JavaScript and Web APIs will help make WebAssembly in practice more "of the Web" while improving performance and ergonomics. Bindings for non-Web hosts embeddings are also relevant.
WebAssembly folks and others can discuss topics of interest.
NOTE: Brad Nelson will be away presenting to the AC.
TBD
- Heejin Ahn
- Jacob Gravelle
- Mircea Trofin
- Eric Holk
- Thomas Nattestad
- Deepti Ganduluri
- Ben Titzer
- Derek Schuff
- Kenneth Cristiansen
- Mark Miller
- Alex Danillo
- Eric Prud'hommeaux
- Conrad Watt
- Limin Zhu
Derek Schuff agrees to take notes.
Eric Prud'hommeaux seconds.
[https://github.com/WebAssembly/meetings/blob/master/main/2017/WG-10-23.md] Ben Titzer seconds
Welcome to TPAC (Brad Nelson).
- Code of Conduct If you are speaking, check out these best practices and speaker guidelines:
- Best Practices for Effective Meetings
- Speaker Guidelines
Great year for wasm, gone from being sort of a thing to shipping in all browsers. Lots of interest, and lots of proposals upcoming.
Introduction of our W3C Team member Eric Prud'hommeaux.
W3C has a process document which describes the roles. Mine is boring bookkeeping! We want a spec process that involves the community enough that people will actually follow it. It’s a blanket process that isn’t necessarily customized for wasm, but it works pretty well. The overall goal is to make the spec resilient, i.e. make it so everyone can implement it. My background/current skills involve JS frontend (and Node), clinical data, C++ libraries.
- We'll talk about where we should be collaborating more with other groups, how we conduct outreach, and plan.
We are here! So let’s take advantage by visiting other groups and talking to folks in our room too. Best to check with the chair before sitting in on an official meeting (fit with their schedule, avoid disruption, etc). Next door is Web Perf team, we will go visit them later. Talking to a broad variety of folks can get us good ideas now rather than later.
Probably no real decision here in the absence of Dan and Andreas. Dan is interested in capturing the state of CSP. We talked about that last week at the CG meeting, but it’s still in flight. It might also be left for a future WG iteration.
EH: which specs?
BN: all 3: core spec, JS and web embeddings.
AD: what’s the plan to turn this from the CG format into a real W3-formatted spec? Those have lots of boilerplate. This still isn’t like those.
EP: We can paste that on the front. Good integration for bikeshed, etc
BN: the embedding specs are BS, but the core is ReST and we kind of like it that way being self-contained.
EP: Can we fit it into a framework that can work?
AD: for a WG recommendation track doc, it has some requirements. So we need to figure out how to fit what we have into those.
BN: We are trying as much as possible to keep the CG in charge of the content. But WG can do reformatting, status section, etc
EP: Some are requirements for publication, some are for convenience. Question is whether the form can be dropped into BS, respec, etc where we can append the extra stuff.
LW: the hope was that the embedding docs could have the webIDL, links, etc.
P?: tradeoffs between the editors and publication process. Do what’s best for the editors, and tooling for publication
EP: also depends on how often we want to publish.
LW: can we put the boilerplate in our BS-based embedding spec and drop in the core spec as a component inside?
Discussion ... maybe? Is the JS-rendered math markup a problem?
P: we’ve done this on other specs, it is possible to include the JS in the published HTML.
KC: Media Capture Depth Stream Extension spec has JS rendering
P: How often do we want to publish?
BN: twice a year?
... We can publish what we have as a working draft. Best to start the patent clocks ASAP How much iteration do we want after? We should have a pipeline to automatically publish as much as possible.
EP: what about the opposite? Doc which just points to editor’s draft.
P: could do that too. Mostly a matter of taste.
BN to follow up with EP on tooling to satisfy the publication rules.
BN: process to kick off public working draft?
EP: add document status, ask for the right short name for spec, warn the lawyers
Plan is to start in 2 weeks at next WG meeting.
EP: also possible to let the editors push the button to publish new working drafts.
End of agenda! Motion to close: let’s get coffee DS enthusiastically seconds
WebAudio folks came by. They demoed a synthesizer built with WebAssembly. It inlines the wasm bytes as javascript text, converts it to an ArrayBuffer and instantiates the module. This is because WebAudio worklets cannot use fetch.
We discussed the current WebAudio worklet proposal. The desire to load wasm more directly was discussed. Eventually when wasm gets ES6 modules support, an import of wasm code would be allowed.
The current api provides buffers to the user application. We discussed a bring-your-own buffer API that would avoid the need to copy audio data in and out of the WebAssembly heap. A protocol to allow WebAudio to request new buffers would be required. Ideally this would allow the main callback for samples to have no arguments, avoiding any chance of a GC.
We talked about if worklets are part of the same Agent Cluster as the rest of the page. Link from Domenic to issue discussing this: w3c/css-houdini-drafts#224
We discussed using the Worklet MessageChannel to pass a SharedArrayBuffer (probably WebAssembly.Memory) / WebAssembly.Module to the worklet. This would allow fetching to happen outside the worklet.
We discussed whether 32-bit floats are still a problem. Consensus was that with this new API, most of the historical issue with larger sample sizes can be worked around.
The general sense was:
- The current API will work fairly well for now, with the use of a MessageChannel.
- It can be later improved with bring-your-own buffer.
- Hosting Bindings might help, but if care is applied won't be blocking.
Representative from Efficient XML Interface EXI WG visited. Recommended we learn more about their compression format.
AI: Add a github issue linking to their spec.
Presentation & Discussion NOTES