Re: [w3c/webpayments-payment-apps-api] Replace setManifest()/getManifest() with set()/get()/keys()/has()/delete() (#95)

@adamroach, clearly, I'm failing at using English - let me try some code and pictures instead. 

A web application need only include:

```HTML
<!-- if the browser supports web manifest -->
<link rel=manifest href="manifest.json">

<!-- worst case, browser supports link rel icon and application-name -->
<link rel=icon href="some-icons.ico" sizes="16x16 32x32 64x64 128x128 256x256">
<meta name="application-name" content="PayPal">

<!-- or proprietary icons --> 
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="icons">
```

Look at PayPal - they already have all this information:

![screenshot_2017-01-25_10_51_35](https://cloud.githubusercontent.com/assets/870154/22272188/bf35303c-e2ec-11e6-9afd-b677c3bc84c2.png)

Also, the "multi-paypal" example is totally bogus. If there are two totally different things, then they would be in totally different origins (hence different apps). In such a case, you would just get different icons:

![screenshot 2017-01-25 11 15 23](https://cloud.githubusercontent.com/assets/870154/22272667/9cf63c20-e2ef-11e6-9655-823594e7bd13.png)
 

> @madmath, wrote "To come back to the question of fine-grained control of payment methods through get()/set()/delete()/etc. I worry that we are introducing a vector for bugs. The Payment App is now responsible for deleting stale payment methods from the list, whereas before it could just say "here's all the payment methods I currently support for this user," which is more consistent with how a server views the world.

This is not the server. That would be like saying, "here are the files for offline"... and that is exactly what AppCache did. And that [broke everything](http://alistapart.com/article/application-cache-is-a-douchebag). It's exactly the same here and we should not repeat those mistakes. 

Hence the fine grained proposal for control over managing payment methods. Additionally, developers  should be able to add, remove, etc. whatever payment methods they want in coordination with the end-user. 

> But I worry that if they don't, or if there is a bug in their implementation, we are left with stale payment methods that the browser has to show, which leads to bad UX.

That's not our problem. You can't stop developers doing bad things. The Cache API doesn't automatically hit the network if it can't find the Response it's looking for. Same here. We expect developers to do the right thing. 

Additionally, the API, given it's asynchronous nature, allows implementers to keep relevant UIs in sync with the web application. So even if the user decides to remove a payment method from another tab, then we can update our own UI. 

> I will defer to you all on the name, but I am effectively advocating for an API to set all supported payment methods at once, overwriting the previous state, and suggesting it should be the only way to control payment methods for an App.

I'm strongly against this position. Developers should be able to add/remove/modify payment methods whenever they want (so long as the user has given them permission to do so) - without affecting other payment methods.


-- 
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/95#issuecomment-274983418