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

About option 3 vs actually using service workers:
> **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.

Clearly in general that’s an anti-pattern we should be trying very hard to avoid for any new features we add to the platform. To me, if we advocate for a mechanism that we know will duplicate a lot of the functionality already provided by service worker, then the burden of proof should be on us (in the Payments WG) to clearly explain to the rest of the people working on features for the platform why we need to create a new parallel thing rather than re-using the work they have already done.

[about basing the payment-apps API on service workers]
> 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.

Me neither. Again I think the burden on proof should be on us in the Payments WG: If we think there is some functionality from standard service workers that we would not want exposed in the payment-apps case, then we have an obligation to clearly identify what that is.

[about not basing the payment-apps API on 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.

It seems to not be clear at all that we need that freedom or that we ever will. So it is not clear that there are any real-world benefits in practice compared to the cost of making users “have to manage the lifecycle of yet another thing” (as @jakearchibald put it).

Another clear benefit of basing the payment-apps API on service worker is, if/when deficiencies in SW get identified that require fixes and refinements—which is a very normal thing that happens with core features of the platform—then for the payment-apps API, we automatically get the benefits of those fixes and refinements for free, without needing to port them over to our parallel thing.

-- 
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#issuecomment-242895035

Received on Saturday, 27 August 2016 04:23:28 UTC