Re: App Manifest & API Proposal

On 12 May 2012, at 19:02, Anant Narayanan wrote:

> Hi everyone,
> 
> I recently joined the webapps working group and I'd like to introduce myself! I work at Mozilla and for the past year or so have been working on our Apps initiative [1]. Our goal has been to make it very easy for developers to build apps using web technologies that can go above and beyond what one might achieve using "native" SDKs on platforms like iOS and Android. We're also trying to make it really easy for users to find and acquire these apps, and use them on any device they happen to own regardless of platform.
> 
> As part of this work we have devised a simple JSON based manifest format to describe an installable web app, in addition to a few DOM APIs to install and manage these apps. We have a working implementation of the entire system in our latest Nightly builds.
> 
> The manifest and corresponding APIs are described in an early draft at:
> http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html
> 
> We'd like to propose using that draft as the basis for a FPWD on this topic. I look forward to your feedback!
> 
> 
> FAQs
> --
> There are a few questions I anticipate in advance, which I will try to answer here, but we can definitely go in more depth as necessary on the list:
> 
> Q. Why not simply reuse the widgets spec [2]?
> 
> A. Aside from naming (we're talking about apps, the word "widget" seems to imply an artificial limitation),

To be fair, you can call your implementation anything you want even if it implements the "Widget" specs. Maybe we could rename the Widget specs "Widgets, Apps, Gadgets or Whatever" specs. 

If you really, really hate the word that much you could decide to call the TWI widget object "app" instead in your own documentation, and just silently convert "window.widget" to "window.app" whenever you come across it. To reciprocate, I could add a line somewhere in Apache Wookie and Apache Cordova that does the exact opposite. Interoperability FTW!

> and replacing XML with JSON;

No objections to representing the manifest in JSON either. Would a serialization of The Widget Interface as a JSON manifest file obviate the need for defining basically the same metadata in a different spec? We can then just focus on the things that definitely aren't part of existing specs, such as the security model, installation events, and default orientation, all of which look like interesting extensions.

> the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps.

Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie + Apache Rave...

> We think hosted apps have several interesting and unique web-like properties that are worth retaining. Hosted apps can be made to work offline just as well as packaged apps with AppCache (which is in need of some improvement, but can be made to work!).

Which are the bits of this proposal that are important for this and which aren't found in Widgets? Can we add those to the existing specs to fill any gaps?

> Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps.

Hmm, that does kind of negate the previous point... but moving on..!

I'm very positive about this proposal and would love to see it merged into Widgets:P&C & TWI, with perhaps a separate spec on web app/widget installation including the work Mozilla has done on installation APIs and events. 

I'd be interested in implementing those in Apache Wookie, Apache Rave and related projects and initiatives that build on them, as web app installation and app store APIs are something thats come up in quite a few implementations and it would be great to have a spec for that. 

Just don't tie it to another competing manifest format, please!

> 
> Q. Why is the DOM API in the same spec as the manifest?
> 
> A. One success condition for us would be standardize the DOM APIs so that users will be able to visit any app marketplace that publishes web apps conforming to the manifest spec in any browser and be able to install and use them.
> 
> We understand there might be other platforms on which a JS API may not be feasible (for eg: A Java API to install and manage these apps is equally important), but that shouldn't preclude us from standardizing the DOM API in browsers. The manifest and the API go hand-in-hand, as we think each of them is dramatically less useful without the other.
> 
> 
> Q. Why only one app per origin?
> 
> A. We originally placed this restriction for security reasons. In Firefox (and most other browsers), the domain name is the primary security boundary - cookie jars, localStorage, XHRs are all bound to the domain. For supporting multiple apps per domain we would have to do some extra work to ensure that (potentially sensitive) permissions granted to one app do not leak into another app from the same domain. Additionally, this lets us use the origin of the domain as a globally unique identifier. Note that app1.example.org and app2.example.org are two different origins under this scheme.
> 
> That said, we've received a lot of developer feedback about the inconvenience of this restriction, and we are actively looking to lift it [3]. We cannot do this without a few other changes around permissions and enforcing specific UA behavior in "app mode" (as opposed to "browser mode"), but is something we can work towards.
> 
> 
> Q. Apps are just web pages, why bother "installing" them?
> 
> A. This has been previously discussed on the list [4]. There are clear differences in perception between an app and a website for most users. Most web content is expected to be free, but the same content wrapped in an app is something people seem to be willing to pay for. Monetization is important to encourage a thriving web developer community.
> 
> Additionally, treating certain "installed" websites as apps gives us a context separate from loading pages in a browser, which allows us to provide privileged APIs to such trusted apps, APIs we would normally not give to untrusted web content.
> 
> 
> Thanks for reading!
> 
> Regards,
> -Anant
> 
> [1] https://mozilla.org/apps/
> [2] https://www.w3.org/TR/widgets/
> [3] https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9482dcd34fa8c1a4
> [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html
>

Received on Sunday, 13 May 2012 19:07:23 UTC