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

There are two ways to use GitHub pages, using a gh-pages branch which allows a per repo website under a single team/user origin or using a single repo per team/user that is the site at the root.

This way GitHub can serve a separate app for each user/team on a different origin. i.e. User's have the choice. 

I suspect that the developers at Github thought about this and that's they don't just render each team/user site at www.github.io/user?

> 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 is not a comparison of manifest and service worker. Extensibility as a concept is about re-use of composable parts. The manifesto may focus on low-level APIs but the same applies to common data models (a key piece of most APIs). Appmanifest defines a data model that could be re-used if the current designed didn't prevent that.

> An app vs site is almost impossible to define, and I don't think it's something the w3c should define.

If the W3C can't define the difference between an app and a site but publishes a spec called "appmanifest" then who can define the difference?

The Web developer's toolkit is constantly growing and yet for some reason the tools are getting more complicated and less consistent which I find frustrating and a bit ridiculous given that there is a group at W3C responsible for technical architecture whose mandate is looking across all of the work and ensuring consistency, interoperability and good architecture.

The ability to define application boundaries for security, execution context etc is basic software architecture but it seems like there are no clear answers on how to define these things.

The best response I've had on this was from @mikewest who said the only true app boundary on the Web is an origin so then I wonder why we'd not enforce that for anything new, accepting that the legacy that is out there must deal with ambiguity.

Payment apps are an entirely new thing. We can define them how we want to and perhaps we should say that only one is allowed per origin?

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

This is not about state storage, it's about decoupling the data model (manifest) from the life-cycle management so that we end up with an extensible, re-usable design. 

If we can acheive that, then when we define a registration behaviour for payment apps that matches algorithms from app manifest, then re-use isn't just "copy and paste" it's actual re-use.

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