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

@adrianhopebailie

> I don't follow this. Github uses subdomains so each Github site is a unique origin.

Unfortunately not:

* https://jakearchibald.github.io/isserviceworkerready/
* https://jakearchibald.github.io/svgomg/

> Re-use of the manifest data model. An "extensible Web" approach to Web architecture.

The extensible web manifesto relates to providing low-level APIs, I'm not sure how the manifest fits into this comparison. The manifest is a pretty high-level API compared to the service worker.

> This data model, a nice generic one that SHOULD be reusable and extensible, is tightly coupled to an installation process that is not. …It's just one of many examples where there are major inconsistencies between W3C specs on simple architectural concepts like what defines an app boundary. Pity the poor fool who wants to become a Web developer 

Let's keep calm about this. An app vs site is almost impossible to define, and I don't think it's something the w3c should define.

The model for long-lived "registrations", that can change over time via a defined lifecycle, is the service worker. It's already being used for this purpose by push, sync, foreign fetch, and soon background fetch. So if the payments WG want to split it down the middle and straddle the SW and manifest for this state storage, then that needs to be justified.

If the reason is because of some common fields (that may or may not be the same as what the site already has), we can probably reuse the algorithms. Eg many specs want "responsive image" like behaviour https://github.com/whatwg/notifications/pull/76.

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