Catch up on posting the meeting notes to the WASI repository.

meetings/2019/WASI-08-15.md

@@ -50,4 +50,72 @@ Installation is required, see the calendar invite.
 
 ## Meeting Notes
 
-Posted after meeting.
+Attendees:
+
+Dan Gohman
+Till Schneidereit
+Alex Crichton
+Luke Wagner
+Jacob Gravelle
+Sam Clegg
+Andrew Scheidecker
+Mark S. Miller
+Johnnie Birch
+Stefan Junker
+Andrew Brown
+
+Meeting notes:
+Topic: Weak Imports: https://github.com/WebAssembly/WASI/pull/47#issuecomment-521061962
+sbc: moved back to custom section design
+[please fill in notes here]
+MarkM: could a rename be considered—I always think of weak references
+Sbc: very strong precedence in C/C++
+MarkM: weak/optional imports should be brought up with TC39
+Luke: [posts a link https://github.com/guybedford/proposal-weak-imports]
+Dan: good question, should we rename?
+Stefan: +1 on “optional”
+Mark: would “optional” be confusing?
+Seems like “no”
+Dan: seems like consensus
+Sbc: [takes an action item to rename]
+Dan: anyone opposed to landing the PR once the rename is done?
+[no]
+Dan: let’s do it
+Topic: Interface description based on Module types (https://github.com/WebAssembly/WASI/pull/74)
+Dan: lots of stuff going on around OCap, and that should go on
+But in parallel, we need a simple text format
+This PR introduces a stripped down text format (see PR description for details)
+
+Mark: should we introduce a term such as “compartment” to describe sets of instances which share memories and tables?
+Sam: This relates to the concept of “shared-nothing linking” which we have been introducing.
+Luke: In full generality, we won’t need the term compartment, because we’ll just have references and different linking approaches.
+Luke: if we want wasi_unstable to become wasi, we need to spec ways to send capabilities between modules. We don’t if we just have references
+Till: brings up the question if we need to support wasi_unstable, instead of just breaking it
+[discussion]
+Mark: This is a useful concept, whether or not it’s something 
+[discussion]
+Luke: getting back to the proposal, looks good for the transitional role
+Dan: idea is, once we have a parser for this, we could land it, and have it be the specification
+Could generate header files and documentation from it
+Sbc: comments go into some kind of comment syntax?
+Dan: double-semicolon
+Sbc: need some kind of include mechanism
+Dan: yes, good point. Want to really keep this simple
+Luke: same requirement came up in conversations with Andreas about defining types in one module and using them in another
+Luke: but as long this is all structural, can just agree on structure of types
+Dan: 
+
+Dan: We need to factor out types so they can be shared between multiple modules. Maybe something like a #include mechanism?
+Mark: #include would be unfortunate in any kind of standards context.
+Luke: We could put multiple modules in one file
+Dan: Could we design a more declarative form which achieves the same goal but doesn’t have the same problem?
+Mark: It’s premature to do a lot of IDL design work
+Dan: agree
+
+Timezone discussion
+Till, Johnnie: conversations about voting, and people not being able to attend all meetings. Perhaps we can find a way to do votes offline to allow people to vote even if they can’t attend the meeting.
+Sam: Another option is to do the vote in the meeting, but hold it open for a week or so after to allow others to vote.
+Till: That does change the dynamics.
+Johnnie: Would it makes sense to record the meetings?
+Dan: What if we ask the CG to record their meetings? We can follow their lead.
+Johnnie volunteers to take that to the CG.

meetings/2019/WASI-08-30.md

@@ -43,4 +43,22 @@ Installation is required, see the calendar invite.
 
 ## Meeting Notes
 
-Posted after meeting.
+Attendees:
+
+Dan Gohman
+Xin Wang
+Leon Wang
+Arun Purushan
+Till Schneidereit
+Tyler McMullen
+Sam Clegg
+
+Meeting notes:
+
+Time zone: 
+XW: Seems like we can move to the previous time.
+DG: We can be flexible in the future too.
+
+XW: Presentation on WASI for Embedded
+
+DG: Update on https://github.com/WebAssembly/WASI/pull/74

meetings/2019/WASI-09-12.md

@@ -36,4 +36,57 @@ Installation is required, see the calendar invite.
 
 ## Meeting Notes
 
-Posted after meeting.
+Attendees:
+
+Dan Gohman
+Sam Clegg
+Pat Hickey
+Yury Delendik
+Artur Jamro
+Mark McCaskey
+Alex Crichton
+Jacob Gravelle
+Mingqiu Sun
+Nathaniel McCallum
+Luke Wagner
+Johnnie Birch
+
+Meeting notes:
+
+Agenda seconded by Pat
+
+Dan: Last meeting was at a different time than usual. There were only 6 attendees. We are going to resume meetings at the normal time, 1600 UTC.
+
+Dan: Next topic is WITX.
+
+Independent of WASI, there is a new file format called WIT from the interface-types proposal. Its a lot like WAT, but it does not have function bodies.
+
+WITX is WIT with extensions. It has some of the types from interface-types. The idea is that WITX is not a stable format, its going to evolve to align with WIT as interface types evolves.
+
+Fortunately our needs are pretty simple at the moment: we are adding strings, arrays, enums, and structs to the wit file.
+
+We want WITX to be the way we specify WASI apis. It feels like a better place than the C header file we started with.
+
+Pat: lucet-idl tool has a witx parser in development.
+
+Working on hooking up this parser to the C and Rust interface generators.
+Goal, be able to feed witx files into lucet-idl and generate C headers and Rust interfaces.
+
+Can be used to generate libc definitions for WASI
+
+
+Stefan: Does WITX have modules?
+
+Dan: Yes, but the file we have at the moment attempts to be the exact same wasi_unstable module we have right now. Once we land this, we can immediately start factoring that module into multiple modules, and witx should support that.
+
+Sam: Is there a way to use types from a different module?
+
+Dan: Yes, there is a `use` mechanism, and in the PR there’s two witx files, wasi_unstable’s first declaration is to `use “typenames.witx”`
+
+Dan: Next agenda item: Phased API development (PR 88). Apologies for getting this up late.
+
+Stefan: Could there be a standalone parser implementation somewhere?
+
+tdoPat: I’ll make the lucet-idl parser and validator for witx into its own crate, and that crate will live in the WASI repo.
+
+Johnnie: I followed up on whether we can record these meetings, I talked to the W3C and they expressed the same concerns we heard here about privacy, making people feel comfortable speaking up. They suggested I talk to the WASM CG, but given that I’ve heard the same feedback from multiple places, I’m going to just drop the issue.

meetings/2019/WASI-09-26.md

@@ -34,4 +34,27 @@ Installation is required, see the calendar invite.
 
 ## Meeting Notes
 
-Posted after meeting.
+Attendees:
+
+Dan Gohman
+Andrew Brown
+Mark Bestavros
+Leon Wang
+Alex Crichton
+Peter Huene
+Luke Wagner
+Yury Delendik
+Pat Hickey
+Artur Jamro
+
+Meeting notes:
+
+DG: WASI modularization draft PR is up, comments are welcome
+
+Also, this makes the start of the point where we can start taking PRs for new API proposals, in the form of PRs which add and modify witx files.
+
+Pat: We’re working on an HTTP API proposal.
+
+Dan: There are also people working on Berkeley sockets APIs. Note that though there is a potential for overlap here, it makes sense to develop both.
+
+Pat: In cases of overlap like this, the higher-level APIs may even by polyfillable on top of the lower-level APIs.