- From: Marcos Caceres <w3c@marcosc.com>
- Date: Tue, 1 Apr 2014 18:42:31 -0400
- To: POTONNIEE Olivier <olivier.potonniee@gemalto.com>, GALINDO Virginie <virginie.galindo@gemalto.com>, Dave Raggett <dsr@w3.org>
- Cc: Mounir Lamouri <mounir@lamouri.fr>, Wonsuk Lee <wonsuk11.lee@samsung.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
On April 1, 2014 at 5:30:50 PM, POTONNIEE Olivier (olivier.potonniee@gemalto.com) wrote: > Sorry, I was not trying to be abstract. I know you weren't, was just pre-empting :) > What I can't see in any specifications is: > > As a web application developer, I want to provide an installable application that users > can download an install on their device. How should I package my application in an interoperable > way? You are correct. Apart from [1], this is vendor specific right now. As I've proposed previously, pulling section 5 "Zip Archive" from [1] would suffice (or simply referencing it from somewhere). Then using the manifest spec [2], would give you 95% of what you need. The missing 5% is adding an "origin" member to the manifest to enable the package app to be CORS-compatible. > Or from the other side: > > As a web application user, I browse to an online page that offers an installable web application. > How can I (or the browser) download this application and install it on my device in an interoperable > way? Yes, you are again correct that the group has no spec for this. Again, [1] + [2] could be used, but [1] would need to be modified to support the JSON format instead of XML. The greater question is why would one do that? Why not just "install/bookmark/add-to-homecreen" the web page (and let service workers deal with offline). This is where we land back at the APIs - but most of the APIs we are defining here would not be available to any random "online page". [1] http://www.w3.org/TR/widgets/ [2] http://w3c.github.io/manifest/
Received on Tuesday, 1 April 2014 22:43:00 UTC