Responses inline.
On Thu, Feb 20, 2014 at 3:43 AM, Dominique Hazael-Massieux <d...@w3.org>wrote: > [resending, think my first attempt went before I finished subscribing] > > 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 think Cordova generally is pretty happy to be bleeding edge, and to add new calls quickly. BUT we are slow to deprecate old APIs, as I discuss more below. We can be both. > * 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 > > Our general approach to date has been to provide both the old and new APIs, with deprecation warnings, and let the old API stand for a few months first. Three releases is our official policy, which nominally means three months, and in practice more like 5 months. Wherever it's possible to implement the old APIs purely in Javascript on top of the new APIs, that is definitely something we want to do. > * how should we proceed when the number of features provided in W3C APIs > is smaller than the ones provided by Cordova? > > I doubt we would remove useful functionality from Cordova, unless it can be attained through some other API. The subset that is standard should still be aligned, I feel. > * 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] > > If they're still useful, then we can make them nonstandard Cordova-only APIs. If the W3C standard was dropped because it turns out to be not useful (eg. network information, from what I understand) then we can decide whether to drop it, or at least to cut it loose and no longer support it. If someone in the community wants to keep such a plugin around, that's up to them. > * 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 > >
