Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
210 lines (158 sloc) 9.03 KB

WebAssembly logo

Agenda for the October 23th video call of WebAssembly's Working Group

  • Host: Google Hangouts
  • Dates: Monday October 23th, 2017
  • Times: 9:00-10:00am Pacific Time
  • Location: Brad will email Google Hangouts link to WG members + registered CG guests prior to the meeting
  • Contact:

Registration

If you are a Working Group member no registration is required.

If you are a Community Group member who would like to observe, please register here: https://goo.gl/forms/HD2kLCM0iSKk7AVl1

Logistics

The meeting will be a Google Hangouts call.

Agenda items

  1. Opening, welcome and roll call
    1. Opening of the meeting
    2. Introduction of attendees
  2. Find volunteers for note taking (chair to volunteer).
  3. Adoption of the agenda
  4. Proposals and discussions
    1. MIME type for wasm
      1. Discussion on if we should seek IANA allocation of 'application/wasm' as the mime type for WebAssembly content.
      2. POLL: We should pursue allocation of application/wasm with IANA. Working Group empowers the chair to register this MIME type on behalf of the WG.
    2. More spec repo logistics (Eric Prud'hommeaux)
      1. ash-nazg integration for spec repo
        • ash-nazg watches for PRs (not branch merges) from folks who are not members of a {W,C}G. There's an interface being substantial vs. editorial. For example, in the bottom of [this](https://github.com/w3c/ServiceWorker/pull/1190 you'll see "All checks have passed". To the right, click and you'll see "ipr — PR deemed acceptable". Example Diff
      2. Given that ash-nazg can be used for checking WG membership, should be consider using an https//github.com/w3c/webassembly-spec repo?
    3. Adoption of CG specification
      1. Discussion of state of the core specification + JS & Wed embedding.
      2. POLL: We should adopt the current WebAssembly core spec as a "First Public Working Draft" for WebAssembly Specification v.1.
    4. Future meetings
      1. Confirm next meeting date + time.
      2. TPAC
  5. Closure

Agenda items for future meetings

None.

Schedule constraints

None.

Dates and locations of future meetings

Dates Location Host
2017-11-01 to 2017-11-02 Santa Clara, CA Intel
2017-11-06 to 2017-11-07 Burlingame, CA TPAC

Meeting Notes

Roll call

  • Arun Purnushan
  • Conrad Watt
  • Edgar Pek
  • Eric Prud’hommeaux
  • Heejin Ahn
  • JF Bastien
  • Peter Jensen
  • Luke Wagner
  • Ben Titzer
  • Derek Schuff
  • Jacob Gravelle
  • Daniel Ehrenberg
  • Sam Clegg
  • Limin Zhu
  • Wouter van Oortmerssen
  • Michael Holman
  • Mircea Trofin
  • Andreas Rossberg

Find volunteers for note taking (chair to volunteer).

JF volunteers.

Adoption of the agenda

JF seconds.

Proposals and discussions

MIME type for wasm

Brad presenting

Discussion on if we should seek IANA allocation of 'application/wasm' as the mime type for WebAssembly content.

  • Added to Web.md along with streaming methods: https://github.com/WebAssembly/design/pull/991
  • Shipping in Chrome.
  • JF: only implication is for streaming APIs?
  • Brad: correct. In particular, Chrome will treat it as an error if the response doesn’t have the right MIME type. This was suggested as a security mitigation (although you can already spoof JavaScript).
  • Luke: Firefox also does application/wasm.
  • Brad: I tried to add it to Python’s source so SimpleHTTPServer would make it work, got pushback because not official.
  • Luke: did the same [with GitHub pages]( Luke Wagner 9:07 AM https://github.com/jshttp/mime-db/blob/master/src/custom-types.json#L267). Should work soon.

POLL: We should pursue allocation of application/wasm with IANA. Working Group empowers the chair to register this MIME type on behalf of the WG.

Unanimous consent

More spec repo logistics

Eric Prud'hommeaux presenting

  1. ash-nazg integration for spec repo * ash-nazg watches for PRs (not branch merges) from folks who are not members of a {W,C}G. There's an interface being substantial vs. editorial. For example, in the bottom of [this](https://github.com/w3c/ServiceWorker/pull/1190 you'll see "All checks have passed". To the right, click and you'll see "ipr — PR deemed acceptable". Example Diff
  2. Given that ash-nazg can be used for checking WG membership, should be consider using an https//github.com/w3c/webassembly-spec Repo?

There are two tools: diffing tool, and membership check tools.

POLL: The group’s advice to Rossberg is that we should add the diffing tool to the spec.

Unanimous consent.

  • JF: what’s interesting is that with our current process we fork each repo for the CG to work on, and then nobody but an editor touches the spec repo. Each of those forks could benefit from this tool.
  • Brad: Eric had mentioned being under the W3C github organization.
  • Eric: tooling is better supported there. May be 5% better for our life.
  • JF: I’d like to discuss separately. Advantage of our own org is we’re admins for it. We can just fork without asking anyone, and adding tools is trivial in the github API. I like having everything under one roof.
  • Brad: How weird does this make us? What do other W3C groups do?
  • Eric: I’ll say 5% (random number) of the groups don’t live under the W3C org.
  • Brad: I assume there will be copies of the final documents under the W3C.
  • JF: I think it’s useful for the tooling to tag contributors as coming from CG / WG for all repos under the WebAssembly github org. Some repos have content which isn’t spec, but may be standardized in the future.

POLL: The group recommends to Rossberg that we set-up ash-nazguh tied to CG membership on all repos other than the spec, and for WG membership on the spec repo. Ideally the tooling would identify membership in WG and CG for all repos.

Unanimous consent.

Adoption of CG specification

Dan Ehrenberg presenting.

Discussion of state of the core specification + JS & Web embedding.

Sent a PR to the WebAssembly spec repo adding JS / Web standardese. Some things are still missing (source map, structured clone, CSP). Please send comments.

  • Brad: my understanding is that source map should be out of scope because even the main source map document isn’t official.
  • Andreas: I already reviewed it. Looks good so far. Only issue is WebIDL talks about very Web things, like DOM string and DOM exception. I don’t know what they mean in a non-Web context.
  • Dan: it just has a funny name, but it’s not Web specific.
  • Brad: would we be comfortable iterating on this towards a first draft?
  • Dan: and before we have CSP integration, and structured clone?
  • JF: I would drop CSP for the first version, and only do structured clone.
  • Mircea: there’s divergence, I’m not sure we want structured clone either. We might want different constraints.
  • JF: OK dropping structured clone as well for first version.
  • Brad: I think that makes sense. Will avoid confusing the issue. I like that we capture the points of strong convergence between browsers in the docs.
  • Dan: are tools a point of strong convergence? Developer-facing display conventions (call stacks, etc).
  • Brad: no.
  • JF: I think this is minor, let’s discuss offline.
  • Brad: agreed.
  • Brad: given that we can drop CSP and structured clone, are we comfortable with these 3 docs as a first public draft.
  • Mike: I definitely have objections. Are we adopting it? It’s just a pull request right now.
  • Brad: it’s true that we haven’t looked much yet, but it’s just a transcription of what was in Web / JS design repo.
  • Dan: I’d definitely appreciate feedback. Some of the changes weren’t typographical.
  • JF: I don’t think we’re in a rush.

POLL: We should adopt the current WebAssembly core spec + WebAssembly JS API + WebAssembly Web API as a "First Public Working Draft" for WebAssembly Specification v.1. Intentionally leaving out CSP and structured clone (to be addressed in a future version)

Brad tables the poll in light of Mike’s objection. We should look at the document more and take our time.

Future meetings

TPAC coming soon.

Confirm next meeting date + time. Wednesday at 9AM on November 15th.

Closure

Adjourned

You can’t perform that action at this time.