On 2010-05-26 19:10, Aaron Boodman wrote:
On Wed, May 26, 2010 at 4:30 AM, Henri Sivonen<hsivo...@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/
