cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <>
Subject Re: Alignment with W3C specs
Date Thu, 20 Feb 2014 14:07:50 GMT
Responses inline.

On Thu, Feb 20, 2014 at 3:43 AM, Dominique Hazael-Massieux <>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:
> 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

> * I understand that APIs need to be preserved between Major releases
> according to ; 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:
> battery
> html media capture
> contacts
> motion
> orientation
> notifications
> File transfer
> I18N
> Media
> Vibration which was marked
> as a dup of
> 2.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message