- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 31 May 2012 14:23:42 -0700
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: ext Anant Narayanan <anant@mozilla.com>, public-webapps <public-webapps@w3.org>, Marcos Caceres <w3c@marcosc.com>, public-native-web-apps@w3.org
Is anyone besides Mozilla interested in implementing this specification? Adam On Wed, May 30, 2012 at 11:36 AM, Arthur Barstow <art.barstow@nokia.com> wrote: > Hi All, > > Besides the thread below that Anant started a few weeks re the Webapp > Manifest spec, Marcos also started a few threads on this spec ... > > What are people's thoughts on whether or not the Quota Management API spec > is ready for First Public Working Draft (FPWD)? > > A "rule of thumb" for FPWD is that the ED's scope should cover most of the > expected functionality although the depth of some functionality may be very > shallow, and it is OK if the ED has some open bugs/issues. > > -Thanks, AB > > On 5/12/12 2:02 PM, ext 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), and replacing XML with JSON; the other >> fundamental difference is that the widget spec describes packaged apps, >> whereas our manifest describes hosted apps. >> >> 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!). Packaged apps do have their own >> advantages though, which we acknowledge, and are open to extending the spec >> to support both types of apps. >> >> >> 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 Thursday, 31 May 2012 21:24:48 UTC