Re: [whatwg/fetch] Deferred fetching (PR #1647)

@fergald commented on this pull request.



> @@ -8449,6 +8597,60 @@ with a <var>promise</var>, <var>request</var>, <var>responseObject</var>, and an
 </div>
 
 
+<h3 id=fetch-later-method>FetchLater method</h3>
+
+<pre class=idl>
+
+dictionary DeferredRequestInit : RequestInit {
+  DOMHighResTimeStamp backgroundTimeout;
+};
+
+partial interface mixin WindowOrWorkerGlobalScope {
+  [NewObject] Promise&lt;Response> fetchLater(RequestInfo input, optional DeferredRequestInit init = {});

@mingyc 
> I don't quite get the synchronous part, how could `FetchLaterState` update itself?

`FetchLaterState` should not update *during* a JS task (unless if has properties that can update in response to some action taken by JS, e.g. if it was `cancellable` then that could change to `false` if you cancel it) and it should not update internally but only become visible later. It should update *between* JS tasks. I'm not sure if synchronous is the right word for that.

Maybe the way to do this is to be specific about the interaction between `sent` and `signal`:
- if `sent` is `false` then aborting `signal` MUST cancel the request and the browser. Cancellation means that that no packets related to that request are/were ever sent.
- if `sent` is `true` then aborting `signal` has no effect.
- if `sent` is `true` then browser has made/is making/will ASAP make an attempt to send the request (this maybe doesn't need to be stated explicitly)


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

Message ID: <whatwg/fetch/pull/1647/review/1471231878@github.com>