Add an agenda for the 03-12 meeting, and add notes for prior meetings (…

…WebAssembly#241)

* Add meeting notes for the past several meetings.

* Add an agenda for the upcoming meeting.

meetings/2019/WASI-11-21.md

@@ -39,3 +39,25 @@ Installation is required, see the calendar invite.
 1. Closure
 
 ## Meeting Notes
+
+Attendees:
+
+Pat Hickey
+Jan Falkin
+Alex crichton
+Jay Phelps
+Andrew brown
+Luke Wagner
+Alon Zakai
+Dan Gohman
+Mark McCaskey
+
+Meeting notes:
+
+DG: WASI Snapshot 1 is out.
+
+DG: WASI-SDK and WASI-libc. Currently in Cranestation orginization. They will move under the WebAssembly orginization, that was approved at the last CG meeting. We just have to work out some minor licensing issues for that to move forward.
+
+DG: Modularization update. I don’t have an update, haven’t had enough time. The current PR shows the shape of it, but it needs to be updated to the current set of APIs and witx.
+
+DG: Call for volunteers. I want to emphasize that WASI is a big opportunity, and now is the time to make changes. Please make PRs against the ephemeral directory

meetings/2019/WASI-12-05.md

@@ -46,4 +46,79 @@ Installation is required, see the calendar invite.
 
 ## Meeting Notes
 
+Attendees:
+
+Dan Gohman
+Pat Hickey
+Stefan Junker
+Wouter van Oortmerssen
+Jan Falkin
+Andrew Brown
+Mark McCaskey
+Peter Huene
+
+Meeting notes:
+
 https://github.com/bytecodealliance/wasmtime/pull/235#issuecomment-518897502
+
+DG: If people have comments on the process we’re following with these meetings, please give feedback.
+
+PH: I’ll second the agenda
+
+DG: First item, stack trace API. Thomas Lively proposed this, but he’s not in the meeting at this time. Let’s table this until he’s here.
+
+DG: Character encodings. This issue has been open for a while and there’s no easy answer. There’s a shape of a proposal in the issue that most engines are following - we say that everything is UTF-8. Is there any disagreement with that consensus here?
+
+(none)
+
+DG: For things like environment variables, it would simplify things a lot if we could guarantee those are UTF-8 strings.
+
+DG: What about filesystems with file names that are unencodable? Can we find a way to tunnel that through? We currently use pointer+length to pass all filenames. No filesystem permits null in a filename, so we can encode a non-UTF8 string by putting extra information after the null. The trouble comes when you have to manipulate the path.
+
+PH: What about interface types interaction?
+
+DG: The stuff after the null will still be valid UTF-8 which encodes the non-UTF-8 part of the filename. So any library code that expects UTF-8 will still work.
+DG: We’ll take this as consensus, and go forward with this design for now. We can change it if problems happen or we have objections during implementations.
+
+AB: Can you clarify what is being encoded after the null?
+
+DG: Two things: in the part before the null we want a normal-looking string, so any bytes that cant be translated get the unencodable-character (uffd). Then, after the null, we put the information that was lost. Something like, index of the string, then the missing bytes. We want something that is reversible. I agree it is goofy. Does anyone know how to encode an arbitrary integer in a utf-8 byte pattern? Obviously we could invent something, like using ascii digits. If theres an existing way to encode it, we’d want to follow that.
+
+AB: So we can’t just say we support all unicode strings?
+
+DG: The problem is that there are names out there that can’t be expressed in unicode. And from people I’ve talked to, its rare in practice. So the goal here is that if you get a path from one wasi api, and treat it as a utf-8 string without manipulating it, and then pass it to another wasi api, it works exactly as is.
+
+AB: I misstated my question - is there no unicode format where this reconstruction wouldn't be necessary? Or will there always be some way for there to be an unencodable string?
+
+DG: My understanding is there’s no way out of this.
+
+Peter H: This would be for bytes which are not valid unicode codepoints.
+
+DG: I’m looking for enough agreement that we can keep designing this for now.
+
+Peter H: is there currently a part of the spec that allows non-utf8?
+
+DG: Witx String type is always UTF-8. We don’t have a byte vector type right now, but there are byte pointer-length pairs. For any string passed to WASI we’ll require it to be UTF-8, and any string coming from WASI would be guaranteed to be UTF-8.
+
+DG: Next topic, case sensitivity in filesystems. If you look at issue 72, the big picture strategy is that WASI doesn’t dictate case sensitivity or insensitivity, or what variation of sensitivity it has (because different filesystems have different rules, whether they case map ascii or different versions of unicode). I think the point of the API is to interact with existing filesystems, and we can’t control those, so this is going to be a portability hazard for WASI. We can make tools that help you detect these pitfalls. Does anyone have ideas of how we can make this better?
+
+DG: Ok, so to use the wasm scary word, it is nondeterministic to use different cases to access the same file in the WASI api.
+DG: Alright, so the next two issues are about virtual terminal handling. Its a space largely defined by compatibility with existing systems like xterm, unix consoles, and windows consoles. It makes sense to have something simple here. You could imagine unifying terminals with GUIs, modernizing terminals, lots of blue sky stuff here. My sense is that the value here is to find a simple thing that will interoperate with lots of different existing systems.
+
+Sbc: Not just to interoperate with existing systems but to allow existing programs to run on many different systems?
+
+DG: Yes my goal is something like vi on wasi just works. It looks like lots of people don’t use terminfo to figure out colors and just hard-code them. And windows support is tricky because it doesn’t have exactly the same features as unix.  In cases where the terminals differ, should we expose WASI programs to the differences between them?
+
+DG: The direction I’m going is we don’t try to do terminfo, the WASI implementation will be responsible for remapping escape sequences and all that. You could imagine having an environment variable TERM=WASI. It would look a lot like xterm, which in turn looks a lot like windows.
+
+DG: On that topic, input sequences are a subfield of escape sequences. Input varies way more than output, across platforms. This made me think we could do a cool radical thing like use unicode symbols. But maybe the simplest thing is, just do what xterm does, and if it needs to be remapped by a WASI implementation to fit another console, thats up to them. But there are interesting questions to still ask here like what set of input sequences to support
+
+DG: Its tempting to say, we can go and design a modern system that doesn’t have all the legacy baggage. But my instinct now is to pull back from that and pick a reasonable set of defaults based on some of the successful modern implementations. If someone wants to design a whole new system, I won’t stand in their way.
+
+SJ: Can you clarify about how vim would work on this?
+
+DG: Vim itself wouldnt have to change. Terminfo is a library that gets linked in, but hopefully we could provide a radically simplified version that works on wasi. Inside the wasi implementation, anything like a TTY would have to filter the output coming from WASI program to neutralize all escape sequences, and then encode in terms of whatever its client expects.
+
+SJ: I would have assumed that stdin/out/err just map to whatever the host of the WASI implementation expects
+
+DG: We’re worried about security, because the terminal interface wasn’t designed to deal with untrusted code running on the terminal. So one example is that you could run a program and you think that it exited, but really its just showing you something that looks like your shell. We want to not allow applications to do things like that, by default. So if you wanted to run vim, you’d have to give it permission to rewrite your entire screen, versus just print ordinary text to stdout, which would be the default. So, controlling cursor position and colors and that would be exposed to wasi as a capability.

meetings/2019/WASI-12-19.md

@@ -37,3 +37,8 @@ Installation is required, see the calendar invite.
 1. Closure
 
 ## Meeting Notes
+
+Windowing and Framebuffer APIs:
+
+There's an early demo out, and it's gotten some feedback. Aarron Turner is
+working on incorporating the feedback and putting together a proposal.

meetings/2020/WASI-01-16.md

@@ -32,3 +32,92 @@ Installation is required, see the calendar invite.
         1. https://github.com/WebAssembly/WASI/pull/193
 
 ## Meeting Notes
+
+Attendees:
+
+Dan Gohman
+Jan Falkin
+Johnnie Birch
+Sam Clegg
+Wouter van Oortmerssen
+Mingqiu Sun
+Andrew Brown
+Alex Crichton
+Peter Huene
+Stefan Junker
+Aaron Turner
+Radu Matei
+Brian Hardock
+Ralph Squillace
+
+Meeting notes:
+
+##Pull 192: https://github.com/WebAssembly/WASI/pull/192
+(...)
+Note SJ: not sure about a conclusion on this one
+
+## Link-time virtualization: https://github.com/WebAssembly/WASI/pull/69
+
+DG: A way to override imports with alternative implementations of the same API
+
+Sbc: How about using the term “interposition” vs “virtualization”?
+(...)
+Sbc: I’m okay with “virtualization” as long as we know we don’t mean dynamic dispatch
+DG: let’s discuss dynamic dispatch. 
+Sbc:  I like the idea of keeping system interfaces simple and not bring in object orientation
+DG: okay, can revisit this later. It’s also tricky cause it depends on features which aren’t done yet, namely interface types and (...)
+Sbc: embedder decides linking, so they could have interposition or not, so the module isn’t in the position to dictate that
+DG: How linking is being done today is not final
+
+Existing virtualization doc: https://github.com/WebAssembly/WASI/pull/69
+
+Close this PR for now, citing the fact that the spec mechanisms we need to do this aren’t well defined yet, so we’ll focus on the simple thing for now.
+
+## POSIX compatibility
+DG: people are surprised that WASI does not align with POSIX. We see justified reasons for this, but it means that applications will have to port to WASI and can’t just recompile for a different target. For compatibility we can have an emulation layer, but for more performance usage to the native syscalls will be beneficial.
+Sbc: agree that we need a compatibility layer for easier transition to WASI
+DG: once we have a better solution for accessing files, a lot of concerns will go away
+
+
+## What should poll for no events do? https://github.com/WebAssembly/WASI/pull/193
+DG: As WASM doesn’t have signal handlers and might never have, does it make sense to poll indefinitely with no subscribers?
+PH: Personally I think it should return `EINVAL` see (https://github.com/WebAssembly/WASI/pull/193#issuecomment-572737431)
+AB: what happens to existing programs if we change this?
+PH: if we start returning EINVAL from this, probably no one’s checking for it
+DG: we could expose the change through a link failure with helpful documentation references. We could also put the feature back in once we have signals
+
+## Framebuffer API https://github.com/WebAssembly/WASI/issues/174
+AT: 
+Sbc: Is this using an mmap’ed file?
+DG: I don’t know the API, but could we mmap the file into the runtime
+Sbc: it probably needs an extra copy for copying between WASI and host memory
+AT: Is this a good idea or do we need WebGL, and only that?
+DG: we don’t have to wait for use cases which require WebGL, and we can implement the simple thing (framebuffer) now
+AT: are there documents on how to get started with new syscalls?
+DG: A C header file would be enough to get started.
+AT: Cool, so I’ll get started on that
+DG: are we going to have an audio API too?
+AT: probably
+DG: we’ll have to be careful about synchronizing the data flow
+Sbc: Will consumers call these functions directly as opposed to using a libc wrapper
+DG/Sbc: (...) probably?
+DG: It’ll be great to have this so other API functions can follow this trail, like bulk copy, clearing the screen. So we can figure out questions like if we should pull those APIs in the WASI SDK, etc.
+
+## Presence on the upcoming in-person meeting?
+Sbc to file an issue.
+
+
+
+
+PE: Will be presenting on an embedder api for wasi at the cg meeting.
+Sbc: maybe we should open an issue to collect items and see if it justifies an in-person meeting
+
+## Status on networking syscalls
+DG: fastly and DG had an in-person meeting to discuss HTTP proxy API. Lots of pressure on network API due to asynchronous requirements, which depends on mechanisms which we don’t have (standardized) yet, e.g. coroutines, expressing synchronicity in interface types, etc.
+PH: where’s this work tracked?
+DG: there aren’t specific issues 
+SBC: Isn’t libevent which is synchronous the defacto standard?
+DG: async depends on which level in the stack you’re looking at. Something which looks async to the application using callbacks, might be using a poll loop a layer below.
+DG: we could have a single event loop for various events which is great for API builders, but not for application builders which might want their own event loop
+SJ: what next steps are required to progress here?
+DG: figuring out async, and then we need a proposal. We want to avoid a system which has either all networking or no networking. Ideally we’d like to have handles. Please reach out to me so we can discuss ideas. 

meetings/2020/WASI-02-27.md

@@ -39,3 +39,54 @@ Installation is required, see the calendar invite.
         - We can also talk about process.
 
 ## Meeting Notes
+
+Attendees:
+
+Dan Gohman
+Mark McCaskey
+Eric Rosenberg
+Mark S. Miller
+Peter Huene
+Yury Delendik
+Luke Wagner
+Daiki Ueno
+Johnnie Birch
+Lee Campbell
+Benjamin Brittain
+Aaron Turner
+Pat Hickey
+Ralph Squillace
+Sam Clegg
+
+
+Meeting notes:
+
+Whole-program LTO coming:
+https://github.com/WebAssembly/tool-conventions/pull/134
+Smaller binary size, optimization of combining libraries with Wasm binary (for example libc)
+Frame-buffer API:
+https://github.com/WebAssembly/WASI/pull/229
+The process for designing and submitting new API proposals is still being figured out, so in addition to the proposal, let's also talk about what we can do to make the process easier.
+Aaron: Idea: add a short and sweet markdown document laying out the steps for a proposal
+Aaron: I wouldn’t mind writing this up. It’s already pretty much already in my PR. So it’s just cleaning that up and we would be good to go :)
+Josh Triplett’s talk at Wasm SF was helpful, but a bit outdated even though it was only given a few months ago.
+
+
+
+Crypto API!
+https://github.com/WebAssembly/WASI/pull/231
+What criteria should we apply?
+We can also talk about process.
+Being developed to support running wasm within a trusted execution environment, but intending this crypto API to have broader use cases.
+Enarx: https://github.com/enarx/enarx/wiki
+Prerequisite for sockets support
+Lots of interest in sockets support.
+Sockets dependency on merging read/write with send/recv?
+Don’t over-rotate on POSIX.
+How much appetite should we have for prototyping?
+Feature flags are a great way to support this
+Declare ahead of time what the process is.
+Maybe it’s ok to use alternate names, as long as we document what’s going to happen. And maybe use polyfills to ease transitions.
+Action item: Dan to write up a brief README for how to prototype a new feature. Also add things to watch out for.
+Separate experimental repo? Directory? Maybe just put features in ephemeral/snapshot 
+Back on read/write - we don’t want to over-rotate on POSIX, but we do want a general read/write? We are heavily influenced by POSIX here.

meetings/2020/WASI-03-12.md

@@ -0,0 +1,37 @@
+![WASI logo](/WASI.png)
+
+## Agenda for the March 12 video call of WASI Subgroup
+
+- **Where**: zoom.us
+- **When**: March 12, 17:00-18:00 UTC
+- **Location**: *link on calendar invite*
+- **Contact**:
+    - Name: Dan Gohman
+    - Email: [email protected]
+
+### Registration
+
+None required if you've attended before. Email Dan Gohman to sign up if it's
+your first time. The meeting is open to CG members only.
+
+## Logistics
+
+The meeting will be on a zoom.us video conference.
+Installation is required, see the calendar invite.
+
+## Agenda items
+
+1. Opening, welcome and roll call
+    1. Please help add your name to the meeting notes.
+    1. Please help take notes.
+    1. Thanks!
+1. Proposals and discussions
+    1. Crypto API now has its own repository:
+        - https://github.com/WebAssembly/WASI-crypto
+        - Let's talk about process and expectations.
+    1. Merging send/recv into write/read:
+        - https://github.com/WebAssembly/WASI/pull/240
+        - This is a complex proposal, but the intention is to simplify
+          the I/O story as we contemplate new kinds of streams and messages.
+
+## Meeting Notes

meetings/README.md

@@ -25,3 +25,4 @@ Meetings of the WASI Subgroup of the W3C WebAssembly Community Group (CG) follow
  * [WASI December 19th video call](2019/WASI-12-19.md)
  * [WASI January 16th video call](2020/WASI-01-16.md)
  * [WASI February 27th video call](2020/WASI-02-27.md)
+ * [WASI March 12th video call](2020/WASI-03-12.md)