Last Comment Bug 673923 - (webapi) New WebAPIs [meta]
(webapi)
: New WebAPIs [meta]
Status: NEW
: meta
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 23 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://wiki.mozilla.org/WebAPI
Depends on: 391286 673917 674062 674066 674693 webusb webbluetooth 677989 gamepad-rumble web-printing camera browser-api 702157 702356 b2g-system-time 721193 721199 721200 keyboard-api 755352 839446 web-crypto 903431 910387 525444 545812 594543 604039 633602 domcrypt 650295 664147 webrtc 673922 674080 674701 674720 websms webtelephony 674728 674734 674739 webnfc 677166 678694 678695 679966 681009 681455 684620 690056 692677 697132 b2g-network-manager 697361 697383 698821 702256 702360 702363 702367 702369 702880 707625 708964 712378 713471 714358 715041 715814 717103 726593 webmobileconnection 736710 746069 alarm-api 751750 system-message-api 776027 796110 871445 inter-app-comm-api 960426 loop_msisdn_verific
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-25 07:53 PDT by Andreas Gal :gal
Modified: 2015-06-01 11:37 PDT (History)
118 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Andreas Gal :gal 2011-07-25 07:53:00 PDT
Tracker bug for new WebAPIs
Comment 1 Mounir Lamouri (:mounir) 2011-07-28 10:31:51 PDT
Chris, bug 594543 is about Desktop Notifications for Firefox Desktop. According to bug 573588 and bug 595094, this is already implemented for Firefox Mobile. Is this bug really depending on the implementation on Desktop?
Comment 2 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-07-28 10:42:53 PDT
I just want to track it to completion.  It's a capability we sorely need on desktop too.
Comment 3 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-08-04 13:37:23 PDT
WAC (http://www.wacapps.net/specifications) has done some work that's relevant here.  Looks like they based their work on W3C WIPs and extended them.
Comment 4 Robin Berjon 2011-08-08 09:49:22 PDT
WAC's APIs aren't Web-compatible, I wouldn't spend much time looking there for this specific project. There might however be value in getting resources from them as B2G is IMHO far closer to what WAC's goal should have been than what they've actually produced to date.
Comment 5 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-08-08 10:17:29 PDT
What do you mean by "Web-compatible"?  I'm not sure and I would like to know :).
Comment 6 Andreas Gal :gal 2011-08-12 16:29:09 PDT
bug 649154 doesn't seem like a strict dependency here
Comment 7 Dave Garrett 2011-08-12 17:16:55 PDT
(In reply to Andreas Gal :gal from comment #6)
> bug 649154 doesn't seem like a strict dependency here

That particular bug is for implementing the DOMCrypt API in a "moz" prefixed window property. The current draft of the spec from there only references Mozilla bug 649154 and bug 657432 as well as WebKit bug 62010. Bug 649154 is where all the current work seems to be, but should a new bug be filed for the final Javascript Cryptography API then that bug would be a better fit here.
Comment 8 Robin Berjon 2011-08-23 08:51:40 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> What do you mean by "Web-compatible"?  I'm not sure and I would like to know
> :).

[Sorry for not replying earlier, I've been on vacation.]

Web-compatible can mean many things and a full definition would be rather long. (In previous discussions on this topic it has been suggested that one should write one such Characterization of the Open Web. Known as the COW document, it is largely believed to be mythical.) I'll therefore stick to the issues that I see with WAC's current specifications.

First, they often fail to integrate with existing Web APIs. For instance they have a File interface which is not the W3C File API and is unlikely to be compatible with it. Interfaces they define that accept files will therefore not accept W3C File objects, and conversely operations that accept W3C File objects will not take WAC files. There are often reasons for such overlaps, usually because the W3C (or other) version of the same functionality is not finalised and a large part of WAC's original goal being to ship an application runtime based on Web technology quickly, at the risk of being dirty. Nevertheless, it doesn't make for a great starting point in general (though ideas can naturally be cherry-picked here and there — smart people have put effort into several of these APIs).

Second, and IMHO far more problematic, is the fact that WAC's APIs have not at all been defined with a Web security model in mind. The assumption is that there is a policy mechanism of some form that selectively enables/forbids specific interfaces or methods for a given application. This may seem minor — why not just front usage of such APIs with some kind of prompt as is done with Geolocation? — but in practice it has deeper implications. You don't want to put something like unfettered file system access behind a simple Geolocation-like prompt and providing specific, subsetted, and properly protected access to privileged device functionality will often require different API designs than if you assume full access in the design followed by some policy-based sieving.

Beyond that one could also mention stylistic issues (which people often refer to as "APIs that look like Java) but I think those can generally be fixed rather easily, and aren't as important.

I believe however that it would be useful to engage WAC one way or another. They have developers, domain experts, testers, real-world use cases, a desire to see Open Web technology power applications, and a number of other things that could open the door to useful cooperation. I just meant to caution about jumping into using WAC APIs as a starting point.

PS: Full disclosure: I've done paid contracting work for WAC in the past and might again. Not that this affects my point of view or that I've been any less candid with them about the approaches I think work best.
Comment 9 Daniel Coloma:dcoloma 2011-08-23 09:23:08 PDT
(In reply to Robin Berjon from comment #8)

> 
> Web-compatible can mean many things and a full definition would be rather
> long. (In previous discussions on this topic it has been suggested that one
> should write one such Characterization of the Open Web. Known as the COW
> document, it is largely believed to be mythical.) I'll therefore stick to
> the issues that I see with WAC's current specifications.
> 
> First, they often fail to integrate with existing Web APIs. For instance
> they have a File interface which is not the W3C File API and is unlikely to
> be compatible with it. Interfaces they define that accept files will
> therefore not accept W3C File objects, and conversely operations that accept
> W3C File objects will not take WAC files. There are often reasons for such
> overlaps, usually because the W3C (or other) version of the same
> functionality is not finalised and a large part of WAC's original goal being
> to ship an application runtime based on Web technology quickly, at the risk
> of being dirty. Nevertheless, it doesn't make for a great starting point in
> general (though ideas can naturally be cherry-picked here and there — smart
> people have put effort into several of these APIs).
> 

Agree that some of the WAC APIs are now superseded by other W3C APIs, e.g. Accelerometer, Orientation and File system come to my mind at a glance. However some of them may be still a good starting point, if not for the final API itself, at least for the use cases that those APIs enable. We (Telefónica) have already developed applications that enable the use cases listed in the WebAPI Wiki on top of a WAC implementation, and the only couple of functionalities we missed in the WAC APIs were a telephony API and another API for managing device settings. 

> Second, and IMHO far more problematic, is the fact that WAC's APIs have not
> at all been defined with a Web security model in mind. The assumption is
> that there is a policy mechanism of some form that selectively
> enables/forbids specific interfaces or methods for a given application. This
> may seem minor — why not just front usage of such APIs with some kind of
> prompt as is done with Geolocation? — but in practice it has deeper
> implications. You don't want to put something like unfettered file system
> access behind a simple Geolocation-like prompt and providing specific,
> subsetted, and properly protected access to privileged device functionality
> will often require different API designs than if you assume full access in
> the design followed by some policy-based sieving.
> 

Yeah, WAC has that policy-based security model, but from my point of view, the APIs are very decouple from the security model. Furthermore, our implementation of the use cases is running on top a WAC 2.0 solution and it works smoothly (with no impact from the security model).

> Beyond that one could also mention stylistic issues (which people often
> refer to as "APIs that look like Java) but I think those can generally be
> fixed rather easily, and aren't as important.
> 
> I believe however that it would be useful to engage WAC one way or another.
> They have developers, domain experts, testers, real-world use cases, a
> desire to see Open Web technology power applications, and a number of other
> things that could open the door to useful cooperation. I just meant to
> caution about jumping into using WAC APIs as a starting point.

I think those are fair statements, and more precise than "WAC's APIs aren't Web-compatible" :) , however, I would say that if there are no equivalent APIs out there for a functionality, it would not harm to have a look at what WAC did. 

> 
> PS: Full disclosure: I've done paid contracting work for WAC in the past and
> might again. Not that this affects my point of view or that I've been any
> less candid with them about the approaches I think work best.

PS: Full disclosure also on my side: I have been also involved in WAC specifications (and working together with Robin in some of them).
Comment 10 jokeyrhyme 2011-08-23 18:46:45 PDT
I would like the suggest that proper management of local storage permissions become part of this specification. Storage quotas / limits, in particular, are abysmally inflexible and non-standard, as per: 
http://dev-test.nemikor.com/web-storage/support-test/

I have filed a separate bug for the storage quota requests here:
https://bugzilla.mozilla.org/show_bug.cgi?id=681545
which is somewhat related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=658117

There is an interesting storage-related issue being tracked against Chromium (Google Chrome) here:
http://code.google.com/p/chromium/issues/detail?id=61676
It deals with unifying the storage quotas so that all persistent mechanisms (webSQL, IndexedDB, localStorage) share a single quota, and all temporary mechanisms (sessionStorage, etc) share a single quota. This approach might be worth evaluating.
Comment 11 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-08-23 19:52:16 PDT
An issue we've discussed but apparently not documented anywhere is that it's possible that the only sane security model for hyper-abusable APIs like telephony or SMS is a URL whitelist, prepopulated by a trusted party like a device vendor (and editable by the user, if they jump through the right hoops).  Rob suggests it could be worth clearly separating APIs intended for the "whitelisted Web" and those for all of it, back alleys and dark corners included.
Comment 12 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-08-24 11:23:03 PDT
Gerv Markham posted some thoughts on using EV certificates as the basis for other mechanisms to grant permissions to web apps

  http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/aaf8c1cf01bf8d1f#

Noting that here so that folks CC'd on this bug are aware of the mozilla-dev-webapi mailing list / newsgroup.  Please post followups to Gerv's post on dev-webapi.
Comment 13 Bryan Sullivan 2011-09-14 19:27:36 PDT
Hi, just joining the discussion here, and pre-disclosure, I am currently involved in WAC and have worked with Robin and Daniel on WAC and W3C (DAP, Webapps).

To Robin's points on the WAC APIs as a basis, particularly re "not Web-friendly":

- Separate the WAC APIs from the policy framework (which is just one way to manage permissions) and its reliance upon DigSig, and the differences pale. A user-preference/permissions feature can be built various ways, and WAC's approach is just one and can be replaced without significantly impacting the APIs.

- W3C is still trying to find its feet on APIs (and their design) outside traditional HTML5 and Webapps Web APIs, for which the declarative/Javascript approaches are fairly well established (WAC chose the Javascript approach also). But outside HTML5/WebAPIs the design approaches in W3C have not stabilized (even RESTful/resource-based approaches to device feature APIs are being considered - maybe they will also be considered here?). Clearly alignment with stable/supported W3C APIs would be a good thing, But until W3C really establishes a pattern for these supplemental APIs (e.g. the ones in B2G's scope), WAC's patterns are IMO just as good as anyone's. Until real rationales for design approaches are clarified, to me its still just a matter of style.

But to be clear: for B2G, which I am very excited to see as a project, I welcome any approach that promotes SDO/initiative convergence, ease of use, and user safety for apps that want to use these APIs. I'll be following and contributing as possible on the mailing list.
Comment 14 Alex Faaborg [:faaborg] (Firefox UX) 2011-10-10 13:52:41 PDT
Hey, do we have any bugs filed yet for device access to:

-proximity sensor
-compass (does MozOrientation cover cardinal directions?)
-accelerometer
-light sensor
-microphone input
Comment 15 Jose Manuel Cantera 2011-10-10 14:17:22 PDT
Those functionalities are covered by the Sensor AP:  http://dev.w3.org/2009/dap/system-info/Sensors.html
Comment 16 Jory Prum 2012-09-26 14:16:18 PDT
Is there a reason there is no mention of Web Audio API on the Web API list?
Comment 17 :Ehsan Akhgari (out sick) 2012-09-27 12:54:48 PDT
(In reply to comment #16)
> Is there a reason there is no mention of Web Audio API on the Web API list?

Bug 779297 tracks the implementation of Web Audio.
Comment 18 matteo sisti sette 2013-06-09 06:44:38 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=881071

Note You need to log in before you can comment on or make changes to this bug.