Open Web Applications Manifest - Comparison with Chrome

[Ben Francis]

Hi,

I'm very interested in the work going on around the Open Web
Applications project and how it compares to the recently launched
Chrome Web Store. I think Mozilla Labs' open approach would definitely
be preferable to Google's currently more closed approach but it would
also be very desirable for multiple browser & OS vendors to support a
common standard.

I've been comparing the manifest formats for Chrome Web Store and
Mozilla Labs' Open Web Applications and I'm wondering what the
position is on compatibility between the two. Is the Open Web
Applications team talking to anyone at Google about this?

The differences I've noticed between the two formats are listed below.

Slight ambiguities in the Mozilla spec:
* Must name be UTF-8 encoded?
* Must description be UTF-8 encoded?

Differences between Mozilla and Chrome manifests:

"base_url" vs. "app" -> "urls"
(Chrome allows multiple absolute URLs, but only one domain if the
manifest isn't hosted in the Chrome Web Store)

"launch_path" vs. "app" -> "launch" -> "web_url"
(Chrome uses an absolute URL, Mozilla uses a relative path)

"capabilities" vs. "permissions"
(What are the possible strings for capabilities and do they relate to
a W3C spec?)

"release" vs. "version"
(Mozilla uses a timestamp, Chrome uses a dot-separated integer)

Mozilla has that Chrome doesn't:
* developer
* locales & default_locale
* installs_allowed_from
* manifest_name (Chrome is always manifest.json, Mozilla defaults to
manifest.webapp)

Chrome has that Mozilla doesn't:
* container (to launch an app in a Chrome "panel")
* key (set automatically by Chrome Web Store)
* minimum_chrome_version
* update_url

Is there any scope for making these formats closer or at least making
it easier for Google to support the Mozilla spec in future?


It's also interesting that at Mozilla Labs you see a differentiation
between "bookmark applications" and "published applications" whereas
Chrome has a distinction between "hosted applications" and "packaged
applications" where no server is required.

I think it's also worth drawing comparisons with the MeeGo Web Runtime
which uses the W3C Widget specifications for installable web
applications which more resemble Chrome's packaged apps.

Do you see scope for standardisation in this area with an organisation
like the W3C in future? I do think what is being done at Mozilla Labs
and Google is something very valuable and quite different to the
current W3C Widget specifications.

I'm looking forward to seeing what comes out of this and to
contributing where I can.

Regards

Ben

Chrome Manifest http://code.google.com/chrome/apps/docs/developers_guide.html#manifest
Latest Mozilla Manifest https://github.com/mozilla/openwebapps/blob/manifest_0.2/docs/MANIFEST.md
MeeGo Web Runtime http://wiki.meego.com/SDK/Docs/1.1/Web_SDK_with_WRT
W3C Widget Specifications http://www.w3.org/TR/widgets/

--
Ben Francis
http://tola.me.uk

[Ian Bicking]

On Fri, Dec 10, 2010 at 8:00 AM, Ben Francis <b...@tola.me.uk> wrote:

I'm very interested in the work going on around the Open Web
Applications project and how it compares to the recently launched
Chrome Web Store. I think Mozilla Labs' open approach would definitely
be preferable to Google's currently more closed approach but it would
also be very desirable for multiple browser & OS vendors to support a
common standard.

I've been comparing the manifest formats for Chrome Web Store and
Mozilla Labs' Open Web Applications and I'm wondering what the
position is on compatibility between the two. Is the Open Web
Applications team talking to anyone at Google about this?

The differences I've noticed between the two formats are listed below.

Slight ambiguities in the Mozilla spec:
* Must name be UTF-8 encoded?
* Must description be UTF-8 encoded?

Ah, I see that encoding is mentioned specifically for those fields, that's an oversight -- encoding is handled at the document level (e.g., with a charset Content-Type parameter).

Differences between Mozilla and Chrome manifests:

"base_url" vs. "app" -> "urls"
(Chrome allows multiple absolute URLs, but only one domain if the
manifest isn't hosted in the Chrome Web Store)

"launch_path" vs. "app" -> "launch" -> "web_url"
(Chrome uses an absolute URL, Mozilla uses a relative path)

"capabilities" vs. "permissions"
(What are the possible strings for capabilities and do they relate to
a W3C spec?)

Right now it's kind of a placeholder for future work, though maybe someone else on the team can reply more specifically.

"release" vs. "version"
(Mozilla uses a timestamp, Chrome uses a dot-separated integer)

Mozilla has that Chrome doesn't:
* developer
* locales & default_locale
* installs_allowed_from
* manifest_name (Chrome is always manifest.json, Mozilla defaults to
manifest.webapp)

Chrome has that Mozilla doesn't:
* container (to launch an app in a Chrome "panel")
* key (set automatically by Chrome Web Store)
* minimum_chrome_version
* update_url

manifest_name is kind of like update_url, i.e., it points to a URL where a manifest exists than can be used to make an update.
 

Is there any scope for making these formats closer or at least making
it easier for Google to support the Mozilla spec in future?

Absolutely, we're open to feedback and collaboration and though there's some drift between these specifications we don't want to unnecessarily create differences (though simple name differences are easy to work around, it's semantic differences that will cause real challenges).  We have been talking to someone working on similar features in Chrome -- from my understanding right now the Chrome App Store is build primarily around their crx extension format, so there's still a bit of room/time to figure out what the document will look like on the web (as opposed to something specifically uploaded to the Chrome App Store).

Fabrice, who has been working on this with Firefox Mobile, I think also put together a quick hack to translate Chrome manifests to Mozilla manifests.  So we'll be playing around with interoperability as well.

It's also interesting that at Mozilla Labs you see a differentiation
between "bookmark applications" and "published applications" whereas
Chrome has a distinction between "hosted applications" and "packaged
applications" where no server is required.

We would like to use the HTML 5 offline features for cases where a server isn't necessary (I guess strictly speaking you still need a server to host the static files, but hosting static files isn't the hard part).  If there's other useful features needed for serverless applications (e.g., data synchronization) we see that as a separate concern from applications.

Bookmark applications are intended to support cases when an application developer isn't adding a manifest themselves, then someone else can write one on their behalf (or we can just guess, e.g., use favicon for the icon).  We're concerned about some security issues in that case, which is why we expect to limit some features for that case.  Mostly if we want to introduce a new UI metaphor this makes it more complete -- so a user won't have some of their apps "installed" but others can't be installed (and presented on the main list) because the site developer hasn't deployed an application manifest.  But this distinction is still something we're trying to figure out.

The differences in how the URLs are specified between Mozilla and Chrome are also related to this.  We're concerned about security problems with multiple domains (specifically the question of who owns what, and who is in control of what) and so we're using the way URLs are specified to force all URLs to be in one location (i.e., each URL is a string to be concatenated to base_url).  I think Chrome has some more flexibility here because they have a signing process, a review process (I imagine?), and a singular store they can monitor and manage.  That their applications are extensions also probably adds to this.

I think it's also worth drawing comparisons with the MeeGo Web Runtime
which uses the W3C Widget specifications for installable web
applications which more resemble Chrome's packaged apps.

We have looked at W3C Widgets some and talked some with people involved with that, but I don't think we've formulated a real comparison yet (on paper or in our heads ;)

Do you see scope for standardisation in this area with an organisation
like the W3C in future? I do think what is being done at Mozilla Labs
and Google is something very valuable and quite different to the
current W3C Widget specifications.

Right now we're trying to explore the space and first make sure what we're building is useful and relevant, but later sure.

  Ian

[marcos]

Hi Ben,

On Dec 10, 3:00 pm, Ben Francis <b...@tola.me.uk> wrote:
> Hi,

>
> Do you see scope for standardisation in this area with an organisation
> like the W3C in future? I do think what is being done at Mozilla Labs
> and Google is something very valuable and quite different to the
> current W3C Widget specifications.

What differences do you see with the W3C Widget Spec? Opera's
extension platform, which is built on the W3C Widget platform, shows
that it is possible to build this class of application on top of the
W3C Widget format. It appears to me that the only real difference is
in the use of JSON instead of XML?

WRT feature permissioning, the W3C Widget format has the <feature>
element. WRT cross domain XHR requests, the W3C Widgets spec relies on
Widget Access Requests.

Kind regards,
Marcos