James M Snell

@Jamesernator: > should web APIs that return async iterators be using ReadableStream instead? Requiring `ReadableStream` in this case would introduce significant additional and unnecessary overhead. I'd very much prefer to...

@domenic > +1 to async iterator over ReadableStream; ReadableStream is designed for I/O I just want to clarify this. Are you saying that we *should* build the async iterator piece...

Ok, so I just want to summarize where we seem to be landing on this: 1. Add a new `EventTarget.prototype.toPromise(type[, options])` that returns a `Promise` that is resolved with `undefined`...

The naming issue there is why I originally was thinking about static methods off `EventTarget` directly... so instead of `window.toPromise('event')` it would be `EventTarget.toPromise(window, 'event')` .. but happy to keep...

Again, just bikeshedding here, but we could flip this around a bit and hang the new API off `Event` instead. ```js const event = await Event.from(target, 'foo'); ```

I've been considering the possibility of a new kind of reader that implements the [`Body` mixin](https://fetch.spec.whatwg.org/#body-mixin), which would provide opportunities for these kinds of optimizations. e.g. ```js const readable =...

@yume-chan makes a great point. This pattern is already possible without making any changes to the streams API by passing a type that explicitly supports this behavior through the stream....

`close()` definitely works over `cancel()` And I could get on board with `follow` with the exception that it's not much better/different than simply attaching an event listener to the signal....

@annevk: > If you can invoke that method multiple times, do we need cancel() or should passing 0 or null be sufficient to clear it? We'd still want the `close()`...

I've opened a PR for `abortController.close()` and `abortSignal.closed` #1042 I'll table the proposal for `abortController.timeout()`