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
