- From: Anne van Kesteren <notifications@github.com>
- Date: Thu, 19 Mar 2015 03:06:33 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/592/83472535@github.com>
(I thought we were discussing this particular API problem in https://github.com/slightlyoff/ServiceWorker/issues/625 but I'm happy to move it here.) @tyoshino we could create `FetchInit : RequestInit` (inherited dictionary) for `fetch()`. I think we should have something distinct from `Request`. @wanderview convinced me that treating `Request` as more than just input (or output in case of a service worker fetch event) is problematic. Various things from the original `Request` object might not end up being taken into account. `fetch()` only modifying parts of the input but not others would be weird. So that leaves us with either a promise subclass or controller of sorts. Given the promise discussions on es-discuss it seems like we want a controller. And as far as @domenic's question goes I think it should be a mechanism that cancels the promise and the stream. The action is terminating network activity. The only worry I have is that the code gets a little awkward: var c = new FetchController, resp = fetch(url, { controller: c }) c.abort() Also, if we go down this route I think the controller object should also expose state whether it is in use or not. And `fetch()` will throw if it is passed a controller that is already in use. Or do we want to allow for the ability of a single controller controlling several fetches? --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/592#issuecomment-83472535
Received on Thursday, 19 March 2015 10:07:00 UTC