My 2c - If the APIs differences are minor, then add deprecation warnings and new methods in-place.
If the API differences are dramatic (e.g. FileTransfer -> XHR2) then create a new plugin. Once the new plugin is ready, we can deprecate the old one as a whole. If the new API doesn't cover all of the features, then refactor the existing API to be implemented on-top of the new standards-compliant one, and use the exec() bridge where necessary to keep the extra features. On Thu, Feb 20, 2014 at 9:19 AM, Dominique Hazael-Massieux <[email protected]>wrote: > Hi Lisa, > > On jeu., 2014-02-20 at 09:13 -0500, Lisa Seacat DeLuca wrote: > > I am a member of the Device API's Working Group and the Web and Mobile > > Interest Group for w3c (with you) as well as a committer for Cordova. > > I'm VERY interested in this alignment as well and would be happy to > > help facilitate a communication channel between the two groups. In > > the past we have created new JIRA issues to track w3c API alignment > > ex: CB-5459 (https://issues.apache.org/jira/browse/CB-5459?filter=-2) > > to align with the vibration spec. Since I attend many of the w3c > > calls I'd be happy to volunteer with your last point of facilitating a > > feedback loop. > > Thanks, that's a great offer that I will take advantage of :) > > That, plus Braden's answer makes it clearer to me how to move forward > now; I'll contact you separately to organize the work on the W3C side of > things. > > Dom > >
