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 = {});

@noamr 
> Perhaps this can be simplified if setting this state is still done on the document's event loop. Needs a bit of research

I think if you want to phrase it in those terms then you have to say something like
- when the browser wants to send the request due to timeout
  - it pushes a task onto the XXX event loop
  - when the task runs:
    - if the request has not yet been cancelled, `sent` is set to `true` and the request can start
    - if the request has already been cancelled, nothing further happens
- when the browser wants to send the request due to freeing up quota allow another request to be queued
  - we don't worry about cancelled because if it's already cancelled we would not think about it at all
  - `sent` is set to `true` and the can request start
- when the browser wants to send the request due to the document having been destroyed (or a crash)
  - the request can start

XXX event loop must be one which continues processing even while in BFCache.

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

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

Received on Friday, 9 June 2023 06:44:22 UTC