annevk, Jake Archibald: I was thinking re. the controller thingy (https://github.com/whatwg/fetch/pull/1329),

maybe instead of returning a struct that fetch exported functions for, to return a struct with algorithm fields, that are set before returning the controller, kind of like how the different algorithms are kept in fetch params).

This way both fetch-params and the state are truly private, and the only thing returned/exported is terminate/abort/finalize or whatever method is operable after the fetch has started. WDYT?

Domenic: In the streams spec, in ReadableStreamPipeTo, the spec says:

If source.[[controller]] implements ReadableByteStreamController, let reader be either ! AcquireReadableStreamBYOBReader(source) or ! AcquireReadableStreamDefaultReader(source), at the user agent’s discretion.

(since the beginning of time: https://github.com/whatwg/streams/pull/512). What does this mean? In what cases should the user agent use which reader type? I can't find any docs in surrounding code snippets.

annevk, Jake Archibald I think one thing that makes SW's "handle fetch" a bit different is that it asynchronously returns a response, rather than receive a processResponse callback algorithm or so.

If we'd change it to be the latter, the SW fetch could return its own controller and the main fetch could terminate it, rather than invert it to where SW has to check whether its caller ("the fetch instance") was terminated.