Skip to content

Latest commit

 

History

History
267 lines (182 loc) · 11.1 KB

WG-09-15.md

File metadata and controls

267 lines (182 loc) · 11.1 KB
Raw

WebAssembly logo

Agenda for the September 15th video call of WebAssembly's Working Group

  • Host: Google Hangouts
  • Dates: Friday September 15th, 2017
  • Times: 9:00-10:00am Pacific Time
  • Location: Brad will email Google Hangouts link to WG members prior to the meeting
  • Contact:

Registration

None required if you've attended before. Email Brad Nelson to sign up if it's your first time. The meeting is open to WG members only (we'll likely broaden this in future meetings).

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. Openness (Brad Nelson)
      1. Discussion on how open the WG process should be.
      2. POLL: We will open up WG meetings to all CG members (for observation).
    2. Mailing list
      1. POLL: We should share the Community Group mailing lists:
    3. Scope of v.1 specification
      1. Discussion on which things should be included in the initial specific, possibilities include:
        1. WebAssembly core spec
          1. Core format
          2. Reference interpreter
        2. Test suite
        3. JavaScript embedding
        4. Web embedding
      2. POLL: We should limit v.1 to core specification only. This excludes: the JavaScript embedding, Web embedding, reference interpreter, and test suite.
    4. Spec repo logistics
      1. Should we branch or fork the repo to capture Working Group state?
    5. Adoption of CG specification
      1. Discussion of state of the core specification.
      2. POLL: We should officially tag and adopt a revision of the spec as the WG input.
      3. Discussion on the process of adopting a "First Public Working Draft" for WebAssembly v.1.
    6. Discussion of coordination with the Community Group.
      1. Discussion of draft phases proposal.
      2. POLL: We should revise the phases proposal to include recommendations on when browsers ship features.
      3. POLL: We should adopt the phases proposal in coordination with the Community Group.
    7. Future meetings
      1. Discussion of timing for future meetings.
  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

  • Ahn, Heejin
  • Bastien, JF
  • Christiansen, Kenneth
  • Ehrenberg, Daniel
  • Ferris, Michael
  • Gandluri, Deepti
  • Gravelle, Jacob
  • Holk, Eric
  • Holman, Michael
  • Jensen, Peter
  • Miller, Mark
  • Nattestad, Thomas
  • Nelson, Bradley
  • Prud'hommeaux, Eric
  • Purushan, Arun
  • Rossberg, Andreas
  • Schuff, Derek
  • Smith, Michael[tm]
  • Tillmann, Nikolai
  • van Oortmerssen, Wouter
  • Wagner, Luke

Find volunteers for note taking (chair to volunteer).

JF volunteers to take notes.

Adoption of the agenda

JF seconds motion to adopt.

Proposals and discussions

Openness (Brad Nelson)

Discussion on how open the WG process should be.

Brad: Trying to be as open as possible. Bound by W3C rules. Folks should feel free to speak freely. Proposal is to allow non-WG members to observe without material participation.

MikeH: How often will we be meeting?

Brad: We'll discuss in a later item, but I was imagining every month, more frequent until we have logistics sorted out.

Brad: The WG is how we produce a formal recommendation, there are legal implications. Mostly a rubber-stamp for the CG work.

MikeH: If we don’t have the meetings that often may be useful to keep closed in case something comes up.

JF: How do other W3C groups handle this?

EricP / MikeS: Not much precedence for this, WebAssembly is fairly exceptional. Started fully-formed. Have tests, implementations, specification. We don’t normally start out this way. This is good. Breaking new ground, we might not have infra / process down for this. One motivation to have a delineation of who’s in the WG is that companies make a patent commitment. Implication of having an open group is that non-WG members could bring IP to the discussion without contributing it. Seems like a small risk, many players have signed on. This is something you should talk to your lawyers about. The CG has a CLA, it’s quite different from the WG. <details omitted from notes, see documents and talk to layer for details>

POLL: We will open up WG meetings to all CG members (for observation).

| SF | F | N | A | SA | | 4 | 13 | 2 | 1 | 0 |

MikeH: If we open for observation, it’s just another CG meeting. We might want WG meetings to be something else.

Brad: There’s no reason we can’t call a closed meeting if need be. If we find ourselves calling closed meetings often then it’s new information which warrants revisiting this poll.

Mailing list

POLL: We should share the Community Group mailing lists:

JF: If goal is to have CG create work, and WG adopt it, then seeing the work progress seems nice.

Brad: Any objections to sharing lists?

Unanimous consent.

Scope of v.1 specification

   1. Discussion on which things should be included in the initial
      specific, possibilities include:
      1. [WebAssembly core spec](https://github.com/WebAssembly/spec)
         1. Core format
         1. Reference interpreter
      1. Test suite
      1. [JavaScript embedding](https://github.com/WebAssembly/design/blob/master/JS.md)
         * [Draft spec](https://littledan.github.io/spec/document/JS.html)
      1. [Web embedding](https://github.com/WebAssembly/design/blob/master/Web.md)

Brad: Have core spec, tests, interpreter, etc. Recently DanE started working on JS / Web embedding. Do we want to split what we publish?

DanE: The JS integration spec isn’t done yet. In a month or two it’ll be in a more complete state.

Brad: Do you think the union of these things forms our spec, or is it more useful to have a V1 of each?

DanE: There are different parts of the web embedding doc. Maybe some would make sense as a separate section.

Andreas: Working assumption in CG was separate specs. Definitely separate documents. They’re written in different styles and tools. About versioning, I don’t know if that matters to keep them common.

Luke: There will be dependencies. JS binding will depend on certain core spec things.

Andreas: True, but we’ll have dependencies on other specs.

DanE: There’s not a solid API surface between them. I wouldn’t want to maintain against multiple WebAssembly versions. I’d like them sort of connected.

JF: Important to understand that JS and Web parts aren’t required for WebAssembly. They’re optional to embeddings e.g. node.js embedding wouldn’t have Web part, and full native embedding wouldn’t have JS either.

Brad: Publishing first draft starts some clocks ticking too.

Andreas: There’s interest in using non-JS embeddings.

Luke: Any restrictions to publishing multiple specs?

EricP: No, only want to make sure what you publish is in the charter.

Luke: Some embeddings might want to make AOT step on install.

JF: I think core question is whether we move forward with a pre-publication for the core spec, which is ready to start now, or whether we wait for JS / Web to be ready. If we move forward we can figure out how to bundle (one doc or multiple) later.

DanE: the JS spec may require some additions to the core spec to expose things, and on the other hand, the JS binding may make changes to what’s shipped by browsers on that end, such as enumerability of methods.

Brad: a useful motivation to move forward is the patent exclusion, and 150 day period. If we start the clock ticking now, then cosmetic changes to the spec don’t reset the clock. If Dan doesn’t uncover anything major then we can talk about first publish. Andreas: I don’t think technical additions will be needed. I think we’ll want to expose hooks and such.

Dan: I agree.

Brad: In the interest of time, let’s table this poll.

Andreas: Question on separating the tests.

Brad: No serious discussion of them being part of the spec.

No objection to moving forward

POLL: We should proceed on a v.1 of the core specification only (not waiting for the JS + Web embedding, which will be separate docs).

      This excludes: the JavaScript embedding,
      Web embedding, reference interpreter, and test suite.

Not polled

Spec repo logistics

   1. Should we branch or fork the repo to capture Working Group state?
1. Adoption of CG specification
   1. Discussion of state of the core specification.
   1. POLL: We should officially tag and adopt a revision of the spec as
      the WG input.
   1. Discussion on the process of adopting a "First Public Working Draft" for WebAssembly v.1.

Not discussed

Future meetings

Discussion of timing for future meetings.

Brad: I was thinking of meeting every 2 weeks for now, and then reducing cadence. Any objections?

None

Brad: Timing isn’t great for Andreas / people in Europe. Anyone from APAC? I was thinking about meeting the opposite week from CG meetings.

Mike: I call in from Tokyo. Time is fine, but we get short end of the stick for all meetings.

Brad: Proposed time would be 2 weeks from now, Tuesday. The 26th of September. We’ve been doing this at 9AM pacific time. Let’s schedule this tentatively.

DanE: This conflicts with TC39.

Brad: Monday September 25th at 9AM pacific time instead?

No objections

Discussion of coordination with the Community Group.

   1. Discussion of [draft phases proposal](https://github.com/WebAssembly/meetings/blob/master/process/phases.md).
   1. POLL: We should revise the phases proposal to include recommendations on when browsers ship features.
   1. POLL: We should adopt the phases proposal in coordination with the Community Group.

Brad: Please consider these. No time to discuss today.

Closure

Adjourn