Re: [whatwg/dom] Abort controller design (#438)

> I thought we needed this for Streams.

I think I may have said that in the past, but I was confused; streams use these only for piping operations, but don't store signals themselves internally. So if you transfer a stream there's no AbortSignal that would go along with it whose transferring/cloning we would need to define.

> I'm not sure I follow, currently a Request object cannot be serialized or deserialized.

Not via structured serialize... but we do something very similar, and hacky, in the fetch spec now, to get it from the service worker to the main thread. (Both Request and Response, I guess.) And the idea would be that, if we send a Request to a service worker, it needs to bring along its AbortSignal, so the service worker can know about any abort requests.

I think the current hacky serialization should ideally be based on structured serialize? Not as sure about that...

-- 
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/dom/issues/438#issuecomment-301889905