Sorry for the late response, I'm catching up on my email backlog. Why: One of the things I think of Cordova as is bridging the gap between point A (standardized HTML5 JS APIs) and point B (what the device vendors implement in their browsers/webviews). We'd love the bridge to not be needed, but alas, that's reality. So one end of the bridge should be aligned with the standards (emerging, finalized, etc.) My impression is that we haven't explicitly been inspecting the alignment, over the course of time there has been some unintentional drift, and we're not as aligned as we ought to be. We should start explicitly inspecting the alignment and correct for misalignments (where reasonable). Then when the device vendors add an API implementation in their browser/webview, there is no cost for an app developer to move from using the Cordova JS API to using the vendor's implementation in the browser/webview. I'd like to think that the recent removal of the Android geolocation code in Cordova is a good example of that.
End goal: the Cordova JS APIs should match the standards. Bonus points if there is no standard and the Cordova JS API is a defacto standard that could seed a future W3C standard. Dominique from the W3C reached out to us earlier [1]. The suggestion is to grab his (or anyone else's) hand and start that inspection and alignment. Although it is a bit old, Dominique also wrote some articles [2] on how to get HTML5 mobile apps on par with native. This seems to be an area of common interest between the W3C and Cordova ;-) [1]: http://markmail.org/thread/yd3fnaixzw2aln7e [2]: http://www.w3.org/blog/2013/03/closing-the-gap-with-native-ap/ On Apr 21, 2014, at 2:33 PM, Parashuram Narasimhan (MS OPEN TECH) <panar...@microsoft.com> wrote: > Hi, > > > I wanted to follow up on the discussion about API Audit and W3C Alignment. > Michael (in CC) from MSOpenTech can help with W3C communications. > > > What should be the next steps on this item? Should we start looking at the > core plugin APIs? The steps could be - > > 1. First, look at cordova core and the core plugins, to identify the list > W3C specifications that are relevant. We should also look at the status of > these specifications. > 2. Prioritize the W3C specs that we care about. This would be based on > popularity of the plugin, and the status of the specifications. > 3. Look at each specification and identify the differences between the spec > and implementation. I think we also need to decide on if it makes sense to > match the implementation to the API 100%. > > Marcel, > > Also, since you suggested this item, can you also document "why" we are doing > this, and what is the "end goal" of this exercise? > > > Raw Notes copied from the hangouts - > > > 1. API Audit / W3C Alignment & "Closing the Gap with Native Apps" > > Owner: Marcel > > * http://markmail.org/thread/yd3fnaixzw2aln7e > > * http://www.w3.org/2013/02/mobile-web-app-state/ > > * http://www.w3.org/blog/2013/03/closing-the-gap-with-native-ap/ > > * http://www.w3.org/wiki/Closing_the_gap_with_native > > * Notes: > > * Lots of w3c overlap with what cordova is doing, but the plugin api's > have diverged a bit in implementations. How do we get back on track? > > * Plugin audit? New plugins? > > * Plugin audit, sounds unlikely we will find the man-hours in short > term? > > * d...@w3.org<mailto:d...@w3.org> filed a bunch of issues on JIRA, but > pretty generic. Lets meet up to discuss concrete actions. > > * Mobilespec type suite for conformance tests? > > * This may be implemented at https://github.com/w3c/web-platform-tests > > * PR against Vibration api. Look at it! > > * What if: less polyfills of specific api, instead generic native features > forwarding to js so others can write polyfills in js-only. > > * Jesse: be more organized so that our implementation doesn't stale, and > that all platforms are all well represented. > > * Jesse: please focus on audio. > > * 2-way communication with w3c. Lisa from IBM has some contacts? MS > opentech also. >
