Dom~ I think you're on the right track starting first by opening the JIRA issues. My thoughts below on your questions...
More specifically: * some of the W3C APIs are more stable than others; should we target to align with all W3C APIs, or only the most stable? If the latter, any thumb rule as to how stable a W3C API needs to be before aligning with it? LD: We should prioritize the list. Which changes are the simplest to implement? Which ones would make the biggest impact if they were integrated. * I understand that APIs need to be preserved between Major releases according to http://wiki.apache.org/cordova/DeprecationPolicy ; if one were to start working on aligned APIs for the various plugins, what would be the best approach: - provide patches that replace the existing APIs with the new (aligned) ones for Cordova 4.x, and add deprecation warnings for the existing APIs in 3.4+ - provide patches that add the aligned APIs in 3.5+, deprecation warnings for existing ones, and reimplement existing ones on top of the aligned APIs LD: As someone else suggested we could create a new plugin separate from the old one and maintain a separate repo until we're ready to switch from the old API to the new ones. * how should we proceed when the number of features provided in W3C APIs is smaller than the ones provided by Cordova? LD: Take it as an opportunity to take those changes to the w3c groups and see if they can add to the specs. That way it's a two way street. Depending of course on the features. If the w3c feels strongly for why those features weren't added to the spec we should have that conversation. It's probably something to talk about on an individual API basis. * how should we deal with APIs that are no longer developed by W3C? I see there was recent discussion on this on the Network Information API for instance [2] LD: Just like you did here the best way to get going on an issue is to send a note to the dev list. * how can we facilitate a feedback loop between the Cordova project and the various W3C groups developing corresponding APIs? I understand that everyone can get very busy on both sides, so I wonder if there is a way to set up a kind of a regular checkpoint that would avoid our common APIs to drift away, and would provide an opportunity to synchronize on the future plans LD: I already responded that I'd be willing to represent Cordova on the DAP w3c working group and Web/Mob w3c interest group as I am already part of those groups. We could also have a smaller task force that meets bi-monthly using one of the w3c bridges to go over status. Lisa Lisa Seacat DeLuca Mobile Engineer | t: +415.787.4589 | [email protected] | | [email protected] | lisaseacat.com | | From: Dominique Hazael-Massieux <[email protected]> To: [email protected] Date: 02/21/2014 09:57 AM Subject: Alignment with W3C specs Hi all, Let me introduce myself quickly: I am part of the W3C staff, am responsible for supervising the mobile-related work in W3C, serve as the “staff contact” for a variety of W3C groups (Web & Mobile Interest Group, Device APIs Working Group, Geolocation Working Group, WebRTC Working Group); I also edit a quarterly overview of Web technologies relevant to mobile: http://www.w3.org/Mobile/mobile-web-app-state/ After some discussion with Brian, I filed yesterday a bunch of issues around aligning Cordova plugins with W3C specs [1]. Given how widely used Cordova is, and given that I understand its goals include to keep the development of hybrid apps as close as possible to standards Web app, I feel it's pretty important we try to keep W3C and Cordova APIs as aligned as possible. I'm interested to contribute myself to that alignment, and to try to get some of the Web & Mobile IG participants to help as well; but before diving into that, I would like to start some higher level discussion on how that alignment should happen, and how we keep the APIs aligned in the long run. More specifically: * some of the W3C APIs are more stable than others; should we target to align with all W3C APIs, or only the most stable? If the latter, any thumb rule as to how stable a W3C API needs to be before aligning with it? * I understand that APIs need to be preserved between Major releases according to http://wiki.apache.org/cordova/DeprecationPolicy ; if one were to start working on aligned APIs for the various plugins, what would be the best approach: - provide patches that replace the existing APIs with the new (aligned) ones for Cordova 4.x, and add deprecation warnings for the existing APIs in 3.4+ - provide patches that add the aligned APIs in 3.5+, deprecation warnings for existing ones, and reimplement existing ones on top of the aligned APIs * how should we proceed when the number of features provided in W3C APIs is smaller than the ones provided by Cordova? * how should we deal with APIs that are no longer developed by W3C? I see there was recent discussion on this on the Network Information API for instance [2] * how can we facilitate a feedback loop between the Cordova project and the various W3C groups developing corresponding APIs? I understand that everyone can get very busy on both sides, so I wonder if there is a way to set up a kind of a regular checkpoint that would avoid our common APIs to drift away, and would provide an opportunity to synchronize on the future plans Sorry for this long message, and thanks for any feedback you might have! Dom 1. namely: https://issues.apache.org/jira/browse/CB-6065 battery https://issues.apache.org/jira/browse/CB-6066 html media capture https://issues.apache.org/jira/browse/CB-6068 contacts https://issues.apache.org/jira/browse/CB-6069 motion https://issues.apache.org/jira/browse/CB-6070 orientation https://issues.apache.org/jira/browse/CB-6071 notifications https://issues.apache.org/jira/browse/CB-6072 File transfer https://issues.apache.org/jira/browse/CB-6073 I18N https://issues.apache.org/jira/browse/CB-6074 Media https://issues.apache.org/jira/browse/CB-6075 Vibration which was marked as a dup of https://issues.apache.org/jira/browse/CB-5459 2. http://markmail.org/message/576zycp5uqcbvni4
