cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
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 <dom@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
>
>

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