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

Yes, good idea. Apologies if my frustrations with understanding the different boundaries between cookies, apps, sw's etc turned things sour. I have a long standing peev with the number of moving parts in W3C specs that don't seem to inter-operate well unless you have some of the tribal knowledge that helps you understand the nuances.

We had a payment app task force call today and this was discussed so I think I can provide some more clarity:

* Payment apps will be ServiceWorkers (the bleeding edge spec from @adamroach provides more detail: https://adamroach.github.io/webpayments-payment-apps-api/#payment-app-manifest)
* The current proposal is to define our own data model that would be input into the ServiceWorker registration process to provide meta-data about the app. As you can see from some of the issue markers we need to deal with many of the same issues that appmanifest has already dealt with like "What is an icon, how do we have multiple icons of different sizes etc".
* A case has been made for putting this data into a file so it can be re-used outside the scope of the ServiceWorker. See: https://github.com/w3c/webpayments-payment-apps-api/issues/33#issuecomment-247026916
* Another reason for having this meta-data available prior to executing the SW registration is that the browser needs some of this meta-data in providing UI to the user to, for example, prompt them to install a payment app they don't have but which is known to support a specific payment method.

So payment apps would benefit from the data model and algorithms defined in app manifest for things like specifying icons but we don't want to buy into the life-cycle management of appmanifest we want to use SW for that.

What could change to make this work "better":
1. Appmanifest defines it's data model using WebIDL and separate algorithms for parsing the JSON and processing the data. This `AppManifestDictionary` could probably replace the [`PaymentAppOptionsDictionary`](https://adamroach.github.io/webpayments-payment-apps-api/#idl-def-paymentappoptions)?
2. Appmanifest describes it's current lifecycle management stuff in terms of it's specific use case and in a way that explicitly says "use this data model in other ways if you want to but this is how we use manifest files via link tags and this is what to expect if that's what you do"
3. Appmanifest includes the possibility of defining a SW instead of a start_url and the "installation" of the app follows the SW lifecycle where the WebIDL defined JS object version of the manifest data is available to the SW during the registration process. This mirros the pattern in other platforms of having a common code base that can be executed differently based on context and runtime parameters (ENV variables, config files etc)

With the following changes a payment app would simply be a specialization of SW that uses appmanifests to define it's meta-data. I may be missing some key considerations here so invite a conversation to clarify at TPAC.

-- 
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-247069062