Thanks Kenji! I've added an "Alternative Considered" section to the explainer mentioning why not using background fetch & background sync APIs.
On Mon, Jul 24, 2023 at 10:04 AM Kenji Baheux <[email protected]> wrote: > The BG sync API requires the presence and control over a service worker. > This isn't possible for third parties, and therefore not solving their > needs. > > But I agree that the explainer could go a bit deeper on those aspects. > > On Sun, Jul 23, 2023 at 1:43 AM Alex Russell <[email protected]> > wrote: > >> I'm surprised not to see a discussion of the (poorly named, but heavily >> overlapping) Background Sync API that we've shipped for many years in the >> Explainer: >> >> https://developer.chrome.com/blog/background-sync/ >> >> Best, >> >> Alex >> >> On Wednesday, July 19, 2023 at 1:26:42 AM UTC-7 Yoav Weiss wrote: >> >>> Thanks for working on this!! (and iterating on the solution based on >>> feedback) >>> >>> On Tue, Jul 18, 2023 at 4:23 AM Ming-Ying Chung <[email protected]> >>> wrote: >>> >>>> Hi Team, >>>> >>>> We plan to prototype the fetchLater API, which is the successor of the >>>> previous PendingBeacon API (intent to prototype mail >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/tPTRZkSmlbg/m/5vGhjrEsAgAJ>, >>>> intent to OT mail >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/ZCVcUEYzVHs/m/3PjKPLmkAQAJ>). >>>> The fetchLater API is the result of discussion >>>> <https://github.com/WICG/pending-beacon/issues/70> with users and >>>> other browser vendors. >>>> >>>> Contact [email protected] >>>> [email protected] >>>> [email protected] >>>> >>>> Explainer >>>> https://github.com/WICG/pending-beacon/blob/main/docs/fetch-later-api.md >>>> >>>> Chromium Design Doc >>>> >>>> https://docs.google.com/document/d/1U8XSnICPY3j-fjzG35UVm6zjwL6LvX6ETU3T8WrzLyQ >>>> >>>> Specification >>>> https://whatpr.org/fetch/1647/094ea69...152d725.html#fetch-later-method >>>> (draft >>>> PR) >>>> >>>> Summary >>>> >>>> fetchLater() is a JavaScript API to request a deferred fetch. Once >>>> requested, the deferred request is queued by the browser, and will be >>>> invoked in one of the following scenarios: >>>> >>>> - The document is destroyed. >>>> - The document is bfcached and not restored after a certain time. >>>> >>>> The API returns a FetchLaterResult that contains a boolean field sent >>>> that may be updated to tell whether the deferred request has been sent out >>>> or not. On successful sending, the whole response will be ignored, >>>> including body and headers. Nothing at all should be processed or updated, >>>> as the page is already gone. >>>> >>>> Note that from the point of view of the API user, the exact send time >>>> is unknown. >>>> >>>> Blink componentBlink>Network>FetchAPI >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EFetchAPI> >>>> >>>> Motivation >>>> >>>> Web developers have a need for ‘beaconing’ - that is, sending a bundle >>>> of data to a backend server, without expecting a particular response, >>>> ideally at the ‘end’ of a user’s visit to a page. Existing beacon APIs >>>> are all based around a developer constructing and sending a beacon, and >>>> there's no good time for that "send" call to be made. >>>> >>>> >>>> This API delegates the sending to the browser itself, so it can support >>>> requests on page unload or on page hide, without the developer having to >>>> implement send calls at exactly the right times. >>>> >>>> Initial public proposal >>>> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776 >>>> >>>> TAG review >>>> TAG review statusPending >>>> <https://github.com/w3ctag/design-reviews/issues/776> (for >>>> PendingBeacon, not fetchLater) >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> >>>> Gecko: Pending >>>> <https://github.com/mozilla/standards-positions/issues/703> >>>> >>>> WebKit: Supportive >>>> <https://github.com/WebKit/standards-positions/issues/85> >>>> >>>> Web developers: No signals >>>> >>>> Other signals: >>>> >>>> WebView application risks >>>> >>>> No >>>> >>>> Debuggability >>>> >>>> fetchLater requests should be shown in the DevTool's network tab, >>>> similar to other network requests. >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ?Not yet. But there are tests for PendingBeacon to convert from. >>>> >>>> Flag nameFetchLaterAPI >>>> >>>> Requires code in //chrome?False >>>> >>>> Estimated milestones >>>> >>>> No milestones specified >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5690553554436096 (old entry for >>>> PendingBeacon API) >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-network-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/ded76e5a-a388-4685-a36c-5cdb92093f15n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/ded76e5a-a388-4685-a36c-5cdb92093f15n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > > > -- > Kenji BAHEUX (my how-to <http://balance/kenjibaheux>) > Product Manager - Chrome > Google Japan > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B_JMTyupioDh70bFFU95vqHpnBSc6KWLxBd%3Dh3itY%2BOs3jzeA%40mail.gmail.com.
