"Grant Leyton Simpson" <glsim...@indiana.edu> wrote: > This is what I had assumed. I love the idea. However, I think > installation is a bad metaphor, given that users will have > preconceived notions about what installation means, namely that > installed apps live on their machine and are under their control (for > the most part). > > > On May 25, 2010, at 10:33 AM, Anne van Kesteren wrote: > > > On Tue, 25 May 2010 16:12:44 +0200, Simpson, Grant Leyton > > <glsim...@indiana.edu> wrote: > >> One question I have off the top of my head is how updates are > >>handled. I > >> like the idea of better integration with the OS and the browser but > >>I > >> don't want to lose one of what I see as the best elements of web > >>app > >> development, namely the need to not have to update clients' copies > >>of > >> the app individually. > > > > Presumably the "installed" app would still be delivered over HTTP; > > potentially with a lot of offline data through storage and a cache > > manifest. "installed" seems to be just a bit on top of what we have > > > already that gives a few extra features. At least that's what I make > > out > > of the rough summary.
I don't think it's a given that everyone who is talking about "installable Web apps" is talking about HTTP plus cache, although I wish everyone were talking about that. Take a look at http://code.google.com/chrome/apps/docs/developers_guide.html There's a zip file with a .crx extension that contains an icon, a permission manifest and potentially the code of the app ("Building a serverless app"). When the .crx file contains the code of the app, a .crx file is essentially like a .wgt file (which is what Opera has been pushing and already has a catalog site http://widgets.opera.com/ ) except with the manifest XML exorcised and replaced with JSON. I think neither .wgt nor serverless .crx apps are Web apps. I think they are local apps built with Web technologies. I think an essential part of an app being a *Web* app is that you navigate in your Web browser to a URL pointing to somewhere out there *on the Web* and the application UI loads into your browser from out there. Now, "somewhere out there" may not be reachable at all times. However, I think stuffing the app into a zip file is an un-Webby way of making an app available offline. I think the Webby way is reading the files of the app from cache when offline but automatically refreshing the client-side files of the app to the latest versions by retrieving them from the server when connectivity works. Thus, I think offline availability should be based on the HTML5 app cache--not on installed zip files. I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides <link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design. A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache. I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To "install" a Web application, the user would navigate to the app's URL and create an application bookmark. To work with the security model of the Web, an application bookmark should probably be considered to bookmark and origin as opposed to bookmarking just one URL. I think having an application bookmark should have the following effects by default: 1) The application bookmark should be displayed to the user in a distinct way compared to regular bookmarks (regular bookmarks are semi-obsolete anyway). 2) Restrictions on resource usage should be very relaxed or entirely removed for an origin that has an application bookmark. That is, the app should be able to consume a lot of local storage space. Rationale: If the user is using an app enough to make an app bookmark for it, the user probably considers the app at least semi-non-hostile and prefers to let the app to be able to do its thing at least in ways that don't involve relaxing privacy. 3) Restrictions on the app leaving evidence of its use on the client computer should be lifted. That is, the app should be able to read and write long-lived first-party cookies and "supercookies" (databases) and should be able to use the HTML5 app cache. Rationale: The application bookmark itself is already evidence that the user is using a given app, so hiding further evidence is pointless. 4) Restrictions on the app causing re-identification of the user to its host should be lifted when a URL whose origin has an application bookmark is loaded to a top-level browsing context. Rationale: Web apps very commonly need some kind of way of identifying the user on repeat access would soon re-identify him/herself to the site anyway. This is so common that it would be bad to have to grant this permission for every app. However, it does not follow that if a user has a google.com application bookmark that the user wants to enable google.com ad or analytics frames on other sites have unlimited cookie or "supercookie" access. 5) Resources cached using the HTML5 app cache by an origin that has an application bookmark should not be implicitly evicted. Rationale: When a user has created an application bookmark, the level of confidence that the app continues to be available offline should be very, very high. 6) Resources cached by the HTTP caching mechanism and belonging to an origin that has an application bookmark should be prioritized for keeping when the HTTP cache needs to evict something. Rationale: Preferential performance and offline availability for origins that are "installed". 7) Restrictions on the use of annoying features such as window.open() and notifications should be lifted for origins that have application bookmarks. Rationale: If the user chooses to use an app heavily enough to create an app bookmark, it's more likely that the user wants to give more UI control to the app than the user would give to a random site and having to explicitly permit e.g. notifications would itself be a usability annoyance. However, I think the creation of an application bookmark shouldn't implicitly expose otherwise private data to the site. That is, I think creating an application bookmark should by default still have privacy properties of a traditional bookmark plus login as far as data exposure to the site's direction goes. It might still be useful to be able to grant additional permissions at the time of creating the application bookmark as opposed to granting permissions one by one when the app tries to use features like geolocation. However, if the permissions can be remembered permanently by origin, I think it not absolutely critical to be able to pre-grant the permissions considering that implicitly allowing local storage already takes care of the most obvious thing many apps would want up front. If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, use <link rel=something> to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names. So what does all this leave to a Web "app store" if there's no .crx file for a store to host? Not much--intentionally. I think the main problem a Web "app store" should solve is discovery. But once the user and the app provider have discovered each other, it's probably not healthy for an open Web for a storefront to have be a third wheel in the relationship forever. Maybe the only technical change to discovery would be having a mechanism for permitting an authorized app store to invoke the application bookmark UI without requiring the user to navigate from the store to the app and then invoke the UI there. There are two other problems worthy of solving: payment and identity. However, I think coupling these with discovery should be optional to avoid lock-in to a winner-takes-all gatekeeper. App providers should be free to use any payment mechanism they choose even if the discovery provider--for convenience--also provided payment brokering. The store provider should be able to act as an OpenID provider, but the user should be able to use any OpenID provider to log into the store and to have store associate payment with that OpenID URL when informing an app of a subscription payment when the store provider handles payment. Informing an app that a given OpenID has paid probably merits an open protocol. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
