[w3c/webpayments-payment-apps-api] The relationship between payment apps and service workers (#33)

A question came up during our last payment apps task force meeting, regarding what the relationship would be between the payment apps in @adamroach's new [payment app proposal](https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md), and service workers. The new payment apps in this proposal do have a lot in common with service workers; 

* They are installed into the browser with a lifespan that exceeds that of the web page that installed them.
* They have the ability to react to certain events (service workers react to fetch requests, payment apps react to payment requests) and pass back a response.
* Many of the [execution lifetime challenges](https://www.w3.org/TR/service-workers/#service-worker-lifetime) and [security challenges](https://www.w3.org/TR/service-workers/#security-considerations) are the same.

The new proposal currently describes payment apps as specializations of the dedicated worker, that just happen to be similar to service workers, but there may be benefits to bringing them closer together. The way I see it, we have at least three options:

**1. Payment apps _are_ service workers**
Going in this direction would mean that we add more functionality to the [`ServiceWorkerGlobalScope`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope). This added functionality would probably consist of a new Event Handler (`onpaymentrequest`) and a function call for registering payment methods or payment options with the user agent. Payment apps are registered exactly the same way as service workers (since they are the same), with `navigator.serviceWorker.register()`. 

The advantage of this approach, is that it is very simple, both to specify and to implement, and it lets us make use of all the security mechanisms around service workers, The disadvantage is that we would be "polluting" the `ServiceWorkerGlobalScope` class with functionality that isn't strictly service worker related. There may also be functionality in service workers that we _don't want_ for payment apps, although I'm not sure what that might be.

**2. Payment apps _inherit from_ service workers**
Inheriting from `ServiceWorkerGlobalScope` rather than modifying it, should let us make use of most of the advantages of the above approach, while keeping our payment request related API separate from the service worker API. We would have to make our own registration method (`PaymentApp.register()` or `navigator.paymentApp.register()`), but this might be considered an advantage, since it would make it clearer what exactly is being registered, and it would let us take additional arguments to the `register` call.

**3. Payment apps _look like_ service workers**
This is the scenario I think the new proposal currently describes. Doing it this way, means that we need to duplicate a lot of the specification (and implementation) from service workers. This way is more work, but gives us the freedom to pick and choose what we borrow from service workers and what we don't.

What do you guys think? You are probably aware of more advantages and disadvantages to some of these options, and it would be interesting to have a discussion on this.

-- 
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/webpayments-payment-apps-api/issues/33