Re: [w3c/ServiceWorker] Add Request Soft Update algorithm for use by other specifications (PR #1847)

monica-ch left a comment (w3c/ServiceWorker#1847)

.

> Thanks for the review — I reworked this around the `Request Soft Update` wrapper and tightened the user-agent discretion wording in [49711d1](https://github.com/w3c/ServiceWorker/commit/49711d11d01c07975febf0ec21e9c9ee7c568c0b).
> 
> * The wrapper requires the requesting storage key and returns when it does not match the registration's storage key.
> * The user agent may return before running `Soft Update`, allowing it to decline requests to protect against excessive resource use.
> * A note explains that implementations can rate-limit requests or treat several nearby invocations for the same registration as one.
> * The note also makes the best-effort contract explicit: callers cannot rely on an update check occurring.
> * The underlying `Soft Update` algorithm remains unexported.
> 
> I used `return` deliberately: WHATWG's algorithm-writing guidance uses it to exit an entire algorithm, whereas “abort these steps” is intended for nested or parallel substeps. Keeping coalescing and rate limiting in the explanatory note avoids making an undefined implementation strategy look like an executable algorithm step.
> 
> FedCM can use this wrapper with its UA-derived identity-handler storage key; the request remains intentionally best-effort rather than guaranteeing that every invocation starts an update.

Agreed and make sense. Thanks for the feedback @yoshisatoyanagisawa. I reworked this to export a  `Request Soft Update`  wrapper instead of exposing Soft Update directly.

It takes a storage key because callers such as FedCM may not have an environment available, but can supply the UA-derived storage key for the request. The wrapper enforces a match with the registration and gives the UA discretion to decline, rate-limit, or coalesce update requests. Callers therefore cannot assume every invocation triggers an update check.

@Brandr0id could you confirm that this best-effort contract works for the FedCM identity-handler flow?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1847#issuecomment-5595764770
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1847/c5595764770@github.com>