You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Dominique Hazael-Massieux <do...@w3.org> on 2014/02/20 09:11:18 UTC
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
Re: Alignment with W3C specs
Posted by Lisa Seacat DeLuca <ld...@us.ibm.com>.
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 | ldeluca@apache.org | |
ldeluca@us.ibm.com | lisaseacat.com | |
From: Dominique Hazael-Massieux <do...@w3.org>
To: dev@cordova.apache.org
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