Specification Review: FetchLater API

[mingyc]

こんにちは TAG-さん!

I'm requesting a TAG review of Fetchlater API.

This is a proposal for FetchLater API. It is a system for sending beacons when pages are discarded, that uses a stateful API rather than having developers explicitly send beacons themselves.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md
• Specification URL: Spec PR/Diff Preview (may be outdated)
• Tests: https://github.com/web-platform-tests/wpt/tree/master/fetch/fetch-later
• User research: positive feedback from various RUM providers testing Pending Beacon API's Origin Trial
• Security and Privacy self-review²: https://github.com/WICG/pending-beacon/blob/main/docs/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): explainer: WICG/pending-beacon/Spec: whatwg/fetch
• Primary contacts (and their relationship to the specification):
  • Ming-Ying Chung (@mingyc), Google - designing/implementing in Chrome
  • Noam Rosenthal (@noamr), Google - API specification
• Organization(s)/project(s) driving the specification: Google (BFCache team)
• Key pieces of existing multi-stakeholder review or discussion of this specification: Deferred fetching whatwg/fetch#1647 Context when pivoted from PendingBeacon API
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/4654499737632768

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: BY Q4 2023
• The group where the work on this specification is currently being done: whatwg/fetch
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
• Major unresolved issues with or opposition to this specification: The PR is not approved yet.
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify @mingyc, @fergald, @noamr

[cynthia]

Discussed during plenary this week. API seems fine, but the naming is a bit strange, "fetch later" could be misunderstood as a deferred fetch, when what you are getting is a guaranteed fetch when the document is gone. We don't have any better suggestions, but just wanted to point out the possibility of misunderstanding.

Explainer could use a bit more spelling out what the user story is. I have some speculations on how this could be used, but that's wildly speculative. Could you add some problems this proposal solves?

[mingyc]

"fetch later" could be misunderstood as a deferred fetch

The current PR (whatwg/fetch#1647) actually calls the algorithm deferred fetching, I think it's intentional.

@noamr FYI

Explainer could use a bit more spelling out what the user story is. I have some speculations on how this could be used, but that's wildly speculative. Could you add some problems this proposal solves?

My bad that the linked explainer does not point to the entry explainer describing the overall goal. Please let me know if the problem description there is clear or not.

Also, I will try to include more story into the fetch later explainer.

[noamr]

Discussed during plenary this week. API seems fine, but the naming is a bit strange, "fetch later" could be misunderstood as a deferred fetch, when what you are getting is a guaranteed fetch when the document is gone. We don't have any better suggestions, but just wanted to point out the possibility of misunderstanding.

I don't really understand this comment. The fetch is deferred to when the document is gone/deactivated. It's called now, and processed at a later time.

[cynthia]

I don't really understand this comment. The fetch is deferred to when the document is gone/deactivated. It's called now, and processed at a later time.

To clarify the sentiment on the naming - it was about the ambiguity of "later" (which can be any time between now and whenever) when it's actually at the point of document destruct (which is much more narrow window than "between now and whenever").

[noamr]

I don't really understand this comment. The fetch is deferred to when the document is gone/deactivated. It's called now, and processed at a later time.

To clarify the sentiment on the naming - it was about the ambiguity of "later" (which can be any time between now and whenever) when it's actually at the point of document destruct (which is much more narrow window than "between now and whenever").

It's actually "any time between now and document destruct or the given timeout, as late as possible". I think "later" conveys this.

[cynthia]

It's actually "any time between now and document destruct or the given timeout, as late as possible". I think "later" conveys this.

Understood. Happy to move this forward in that case, thanks!