Re: [whatwg/fetch] WIP: Cancelation (#523)

> FWIW, I think I'm generally on board with [@jakearchibald](https://github.com/jakearchibald)'s approach.

Which is this, exactly? Do you mean https://github.com/whatwg/fetch/pull/523#issuecomment-307404328 ?

In general I don't care much about the non-streams aspects and am happy to let you all figure it out; I was just trying to help while you were away.

> If [@domenic](https://github.com/domenic) wants to double down on JavaScript vs system layer separation I'd be okay with that (and might help implementers a bit)

I do think we should keep things separate where possible.

> but then we should do the same for streams.

I've been thinking about how to do this for a long time. It sure would be nice. I'd like to do it later though.

> That also doesn't really preclude using signals I think. We'd just need to be able to use them abstractly and make the JavaScript API a wrapper.

My point of view is that most of the features of signals are designed around delegation of authority in JavaScript objects. I.e., you can give someone a promise or a Request or a Response or whatever, and if they don't have the AbortSignal, they cannot abort it. This is similar to how you can give someone a promise, but without the resolve/reject functions, they cannot change its fate.

But in spec land that separation just gets in the way. For promises, in spec land we happily say "resolve p with x" on implementation-created promises, with the understanding that this is theoretically translatable to tracking a (p, resolve) pair throughout the system, but we don't want to write that down explicitly. (And indeed at least Chrome implements it with direct access, not a (p, resolve) pair.)

So I think it's simpler to understand if we don't involve the signals at all in aborting a fetch, but instead simply define primitive operations like "abort the stream" or "abort the request" or similar and use those directly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/523#issuecomment-315840918

Received on Monday, 17 July 2017 18:29:39 UTC