[whatwg] Installable web apps

[Lachlan Hunt]

On 2010-05-26 19:10, Aaron Boodman wrote:
> On Wed, May 26, 2010 at 4:30 AM, Henri Sivonen<hsivonen at iki.fi>
> wrote:
>> 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.
>
> This isn't really the point of this mail, but I just want to point
> out that there are more differences between wgt and crx than the
> format of the manifest file. The most important is that the identify
> of a crx file is a public key, and all crx files are self-signed by
> their key. This makes a crx file's identity unforgeable.

There are, however, a lot of similarities between your proposal and 
widgets.  I compared the manifests of both crx and widgets, and I 
believe the metadata included in crx maps to that in widgets as follows:

*Chrome Manifest* | *Widgets Manifest*
(implied)         | <widget viewmodes="windowed">
name              | <name>
version           | <widget version="...">
icons             | <icon src=""
- 24              | ... height="24" width="24">
- 128             | ... height="128" width="128">
permissions       | <feature>
web_content       | <access
- enabled         | (implied)
- origin          | ... origin="...">
- paths           | N/A - what's the purpose of this, why is it needed?
launch:           | Default start file, e.g. index.html, or
- web_url         | N/A
- local_path      | <content src="...">

Digital signatures are also supported in widgets.  Are there any 
limitations that you are aware of with widgets-digsig compared with crx 
signatures that might make them unsuitable?

http://www.w3.org/TR/widgets-digsig/

> I completely agree that app cache is a more "webby" way of making
> apps available offline than packaging. In particular, app cache
> preserves the ability to deep-link into an application, which is an
> important characteristic of the web.
>
> The source of our support for packaged applications is that we have
> gotten a lot of feedback from developers that find packages a very
> convenient way to develop applications that work offline. I think
> the reason is that packages are conceptually much simpler than app
> caches. That said, I think this is mainly a lack of good tool support
> for app cache and good documentation, and I think it can eventually
> be overcome.
>
> For now, I would like to focus on live web apps, not packaged local
> apps.

Fair enough.  I think widgets already cover the packaged local app cases 
anyway.

>> 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.
>
> For Chrome this isn't the UX we want. We want users to click a link
> in the content area and be presented with an install dialog. We
> think that going to something in the browser to "applicationify" a
> web app is too indirect and that many users will not get it.

That was the user experience offered by Safari 4 beta's experimental 
Save as Web Application feature and Mozilla Prism.  I can understand why 
that is perceived as suboptimal for many users.  But they had the 
advantage of allowing the user to turn any website they wanted into an 
application, whereas your proposed model depends on the site explicitly 
providing an application to install.  There are benefits to both models.

> That said, I think there is room to support multiple models of
> installation (or bookmarking, or whatever you want to call it),
> though.

Indeed.

>> 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.
>
> We have a growing set of metadata you're trying to<link>  to:
>
> - Icons

<link rel="icon" sizes="24x24" href="icon.png">

> - Application name (you didn't mention this, but I think it
> is nice to have distinct from the<title>, which is often overloaded
> with status information)

<meta name="application-name" content="...">

>  - Any permissions

Not yet available.

> To me, this all leads to the following proposal:
>
> <html>
> <head>
> <!-- for UAs that want a button in the browser chrome to appify -->
> <link rel="application-description" href="myapp.json">
> </head>
> <body>
> <!-- for UAs that want a button in the [content area] to appify -->
> <button onclick="navigator.installApplication()">install</button>

This is reminiscent of the old <bb> element proposal that used to be in 
HTML5.

<bb type="makeapp">Install application</bb>

http://www.w3.org/TR/2009/WD-html5-20090423/interactive-elements.html#the-bb-element

Another alternative would be to use a link relationship perhaps link to 
either a manifest or to the URL of the application itself.

e.g. <a href="htts://mail.google.com/mail/" rel="application">.

This could work analogously to rel="sidebar", where some browsers 
recognise that and prompt the user to load the link in their sidebar. 
Although, in this case, it could prompt the user to install the app instead.

> // myapp.json
> {
>   "name": "My Application",
>   "icons": ...,
>   "urls": [
>     "reader/"
>   ],
>   "permissions": [
>     ...
>   ]
> }

I wonder if there would be a way to integrate this extra information 
into the existing cache manifest file, or into the HTML with <meta> and 
<link> elements, rather than creating a whole new manifest file format.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/