Re: [w3c/manifest] Bring back "serviceworker" member (#864)

> Would it make sense to have a "payment" field inside Web App Manifest? The field can contain payment specific fields like "serviceworker".

The problem with this is that the other cited examples are nested within another existing member (`related_applications`). But that is one option. It feels weird to me having both a Payment Method Manifest _and_ a `payment` dictionary within the Web App Manifest.

So the options are:

1. `serviceworker` inside the Payment manifest.
2. `serviceworker` inside the Web App Manifest, but only used by payments for now.
3. `serviceworker` inside the Web App Manifest, intended to be used generally to install a service worker without loading a page. (i.e., its original intention)
4. `payment.serviceworker` inside the Web App Manifest.

The difference between 2 and 3 is perhaps not a spec difference, just implementation. The payment spec might _mandate_ that `serviceworker` is used, but the web app manifest spec would not mandate its use for general installation, though user agents would be able to use it for that (for example, a store listing could install the service worker without having to load the page).

I would be in favour of 2 (which basically means reverting this), but then I think w3c/payment-handler#346 needs to be resolved so that there's an actual client of this in a spec (not just in a browser).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/864#issuecomment-626420409