W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: App Manifest & API Proposal

From: Anant Narayanan <anant@mozilla.com>
Date: Sun, 13 May 2012 09:50:34 -0700
Message-ID: <4FAFE65A.9020101@mozilla.com>
To: public-webapps <public-webapps@w3.org>
On 5/12/2012 2:57 PM, Marcos Caceres wrote:
> On Saturday, 12 May 2012 at 21:14, Ian Hickson wrote:
>> The "installation" security model of asking the user up-front to grant
>> trust just doesn't work because users don't understand the question, and
>> the "installation" security model of curating apps and trying to determine
>> by empirical examination whether an application is trustworthy or not just
>> doesn't scale.
> I agree with Ian about the above, which is why I was hopeful that "feature" thing is not needed in the manifest format (or the manifest format is not needed at all). "Features" have historically enable proprietary APIs (in Chrome extension, Opera extensions, and WAC for example), which likely won't interoperate (so features will also require standardisation).
> In my email I said that we (the widget-side of the Webapps WG) were hopeful that HTML would provide the needed app metadata to allow apps to be "installed" in some meaningful way (e.g., HTML provides icon support already, and I think Opera exploits this in speed dial - which serve a similar purpose to a installed app/visual bookmarks).
> So I'm left wondering, what is missing (if anything) from HTML to meet the use cases that Moz's proposed manifest and API sets out to provide?

The big difference is runtime vs. install/launch time. As I noted in the 
other review email, we'd like to give developers, stores and UAs a 
little more information about any given app before they actually let the 
user purchase/install/launch the app.

Received on Sunday, 13 May 2012 16:51:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:40 UTC