Re: [w3c/webpayments-payment-apps-api] Multiple payment apps per origin (#98)

@jakearchibald,

> Service workers can already import scripts, and that gets even easier with es6 imports. So it isn't true that we'd be forcing developers to use the same script.

I didn't mean to imply that there wasn't an alternative route to accomplishing code division, but we *are* closing off one route for doing it. My default position is: Don't close off routes for developers unless you have a good reason to. If there would be "massive complication" if we didn't close off one route then that's a perfectly good reason to do it, especially when we can offer the developer a slightly different alternative to what they'd like to do. I'm just not sure what the massive complication is that you're referring to. However, I have specified a concrete complication above that I think is sufficient to warrant restricting payment option registration in the way that you suggest. So we're in agreement now, but perhaps for different reasons.

> By adopting something that wraps service workers, you're now having to define a whole new life cycle. Also, developers will have to manage the life cycle of service workers within this life cycle.

My suggestion above was not to wrap service workers, it was to decouple grouping information. It was to simply let the developer say, in a service worker registration:

"Offer this option to the user and show it under the banner of payment app X."

If no service worker registrations exist with payment options for payment app X, then nothing is shown under payment app X. There is no additional life cycle beyond service workers and nothing new to manage.

-- 
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/98#issuecomment-280750567