Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

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