Re: [w3c/manifest] Integration with service workers (#161)

> My original proposal was that payment apps could be a use case for motivating that app manifests be used to provide meta-data when registering a ServiceWorker.

Why? Why go through the manifest processing dance? why go to the network for a manifest file at all? That makes little sense to me. One is free to compose the payment details from the payment application from the manifest (e.g., if you want to pull resources or the manifest out of cache storage), but relying on the manifest and processing model seems wrong.

> I still think there is value in re-using the data model from appmanifest to describe the meta-data about a payment app (icon, labels etc) but we can't use the appmanifest spec directly because it couples the use of the manifest data model tightly to it's own installation algorithms.

This is by design. It's serving a very particular and limited purpose to do with installation and OS integration. 

> This is a pity given that in most cases a payment app is likely to be far closer to the metaphor of an app as understood by most people than anything currently using app manifest.

I'm sorry, but that's a bogus claim to make. Firstly, 99% of the time, payments are going to be going through the OS preferred payment provider (i.e., Apple Pay or Android Pay). 

The (web) applications that hook into the payment providers are the ones that provide value - by affording the actual acquisition of goods and services: the payment providers are appendages, much like PayPal is for eBay, etc. If payment providers make nice (web) apps, then they will get installed too. But no one shouldn't have to "install" a payment provider's app - only have enough details for a monetary transaction to take place. 


-- 
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/161#issuecomment-246617734