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.

Welcome to the club! :)

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

Re: icons, we might be able to push that stuff down the stack to HTML. It's where "responsive images" are defined. The manifest spec leverages HTML and fetch where it can, because we want both the security assurances and the consistent behavior. 

Another spec dealing with icons is Notifications - so it also provides a good place to look (though it currently doesn't do responsive images for icons, AFAICT). 

> 1. Appmanifest defines it's data model using WebIDL and separate algorithms for parsing the JSON and processing the data. This AppManifest could probably replace the PaymentAppManifest or just be extended by it?

Need to do this regardless. I've had similar requests internally. However, we still need to go through the processing step to clean up the manifest's data to get something that can be fed to the IDL machinery.

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

Yep?

> 3. Appmanifest includes the possibility of defining a SW instead of a start_url

That doesn't make sense to me. But it could define an SW in addition to the 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.

If installation is triggered from the manifest, then sure. But why can't you just fetch it? Why do you need the clean object?  

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

Let's not jump the shark. Remember you can still get the manifest simply by:

```JS
addEventListener("install", (ev)=>{
    ev.waitUntil(async function(){
        const res = fetch("manifest.json");
    })
}); 
```

The question is, what do you then want to do with the manifest data? 
 

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